{"id":964,"date":"2025-08-20T06:06:19","date_gmt":"2025-08-20T06:06:19","guid":{"rendered":"https:\/\/pixelfat.com\/home\/?p=964"},"modified":"2025-09-01T07:27:35","modified_gmt":"2025-09-01T07:27:35","slug":"unity-namespaces-and-mvc","status":"publish","type":"post","link":"https:\/\/pixelfat.com\/home\/unity-namespaces-and-mvc\/","title":{"rendered":"Part 3: Structuring Projects with Namespaces, MVC and MVP"},"content":{"rendered":"\n

If you\u2019ve been following along, you\u2019ll notice our domain-based<\/a> folder structure naturally supports another important practice we should be enforcing in all C# projects: proper namespaces<\/a><\/strong>.<\/p>\n\n\n\n

A C# class\u2019s namespace should always closely mirror its file path so that at a glance, we know what context, file and domain we’re in, but in our case we need to ignore Unity-specific quirks like Assets\/<\/code> or Scripts\/<\/code>. Either way, if your structure is clear, you should be able to look at a namespace and immediately know where the file lives, and vice versa.<\/p>\n\n\n\n

Example Structure<\/h6>\n\n\n\n
Assets\/pixelfat\/CandySmushSega\/Scripts\/Application\nAssets\/pixelfat\/CandySmushSega\/Scripts\/UI\nAssets\/pixelfat\/CandySmushSega\/Scripts\/Model\nAssets\/pixelfat\/CandySmushSega\/Scripts\/Game<\/code><\/pre>\n\n\n\n
Matching namespaces<\/h6>\n\n\n\n
pixelfat.CandySmushSega.Application\npixelfat.CandySmushSega.UI\npixelfat.CandySmushSega.Model\npixelfat.CandySmushSega.Game<\/code><\/pre>\n\n\n\n
\n
But Dan<\/em>, you say, I’m making a game, not an app<\/em>..<\/p>\n<\/blockquote>\n\n\n\n
Well, that\u2019s not strictly true. Your game<\/em> is just one feature<\/em> of the application<\/em> that delivers it. If you keep that in mind, you can use namespaces to write naturally decoupled <\/strong>code with much less effort, which is a huge win for everyone. And as the lead, senior or architect, you can use these patterns to encourage others to write naturally decoupled code too. So, if we were to keep our game outside of our applications layers and instead have them consume the game, we can do whatever is best for our purpose and even switch out the game or reuse the application layers in other projects.<\/p>\n\n\n\n
<\/span><\/figure><\/div>\n\n\n\n

By keeping your layers and systems separate, it’s easy for any developer to recognise an overall MVC (or rather, MVP) pattern in the application <\/strong><\/em>and overall project structure with no confusion as to where things are or should be. All while allowing your game code<\/strong><\/em> to follow whatever pattern best suits it.<\/p>\n\n\n\n
The Right Tool For Each Job<\/h3>\n\n\n\n
If we write our game-specific code in pixelfat\/CandySmushSega\/Game<\/code>, then our namespace is naturally pixelfat.CandySmushSega.Game<\/code>. The application that consumes it lives in pixelfat.CandySmushSega.Application<\/code>. This means the application<\/strong> can create instances, invoke methods, and subscribe to events in the game<\/strong>, while the game has no knowledge of the application at all. It only needs the app to start it, pass in resources, and handle events.

Namespaces are practical guard rails. They guide your devs (and future you) into the right place to implement each feature. But they are also used to separate concerns, systems, data models and everything else. So, while you may steer away from MVC because you’ve been taught it’s an anti-game pattern, we can still use it for what it’s best at – organising our application code.<\/p>\n\n\n\n
<\/span><\/figure><\/div>\n\n\n\n

With domain-driven structures<\/a> and namespaces in place, we can now apply MVC<\/a> (or any other pattern you deem fit) where it fits best: in the application layer, while allowing our game devs the freedom to use any pattern they want in the game code. Personally, I like to stick with MVP<\/a> for games as it’s very similar to the MVC pattern I use for applications, and works well with Unity scenes and component structure.

This way, game logic doesn\u2019t bleed into UI or presentation, and namespaces provide the road markings that keep every developer in their lane. And by every developer, I mostly mean future me. Drink water before bed, write clear namespaces, future you will be grateful.<\/p>\n\n\n\n
Don\u2019t just take my word for it:
https:\/\/unity.com\/resources\/level-up-your-code-with-game-programming-patterns<\/a>
https:\/\/stackoverflow.com\/questions\/2056\/what-are-mvp-and-mvc-and-what-is-the-differenc<\/a><\/p>\n\n\n\n
So, we can now have something like this:<\/p>\n\n\n\n
using pixelfat.CandySmushSega.Game;\n\nnamespace pixelfat.CandySmushSega.Application\n{\n    public class CandySmushSegaApp \/\/ controller\/presenter\n    {\n        public CandySmushGameView GameView;    \/\/ view\n        public CandySmushGame GameInstance;    \/\/ model\n        public ICandySmushInput GameInput;     \/\/ input, specifically for the target platform\n\n        public CandySmushSegaApp()\n        {\n\n            \/\/ Create a game instance\n            GameInstance = new CandySmushV1();\n\n            \/\/ Attach the input system\n            GameInstance.SetInput(GameInput);\n\n            \/\/ Subscribe to events the application cares about (game over, etc)\n            GameInstance.OnEvent += HandleEvent;\n\n            \/\/ Attach a Unity view component to present the game\n            GameView = new GameObject(\"Game View\").AddComponent<CandySmushGameView>();\n\n            \/\/ View subscribes to state\/events, does any setup it needs\n            GameView.SetGame(GameInstance); \n\n        }\n\n        private void HandleEvent(object sender, GameEvent e)\n        {\n            \/\/ Translate game events to app\/UI actions\n        }\n    }\n}<\/code><\/pre>\n\n\n
Note: There are many<\/strong> ways to create a game instance, hook up input, implement a presentation layer, and handle it through your application, the above is just one example. You may want to just instantiate a prefab ICandySmushGame<\/em><\/em> GameInstance = Instantiate<ICandySmushGame<\/em>>(prefab) and that’s it.. which is perfectly fine too<\/em>! <\/p>\n\n\n
\n
Could we go further? <\/p>\n<\/blockquote>\n\n\n\n
Sure, we could implement an interface IMatchThreeGame<\/code> have our application use only that. We can write wrappers for many off-the-shelf match three solutions that implement it and have several completely different implementations of match three in our project. Then we can switch out the game code whenever we like, without affecting the application part at all. <\/p>\n\n\n\n
\n
Should we go further? <\/p>\n<\/blockquote>\n\n\n\n
Not unless switching out the game is either a part of your agreed upon scope<\/strong>, or on the roadmap<\/strong>. Many senior or lead devs will push for the use of interfaces early, but there’s rarely any reason to do so unless it’s a part of the current requirement. So don’t be ashamed to dump your entire game in a prefab and just directly reference the class returned when you instantiate it. If that\u2019s all the requirement calls for, that\u2019s good architecture. Pedantry is not. Just make sure you can switch it up for an interface if it does become a requirement later.

What you shouldn\u2019t<\/strong> do is end up with buckets like Game.Core<\/code> or Application.Controller<\/code>. Those names hide intent and erode boundaries. This mapping isn\u2019t just about cleanliness – it enables better IDE navigation, refactoring, code reuse<\/strong>, and on-boarding. It also stops you from dumping everything into one giant Scripts<\/code> folder and hoping for the best.<\/p>\n\n\n\n
But try not to take everything I’m saying here verbatim, as an architect it’s up to you to figure out what the best tool is for the job, then figure out how to best use it – I’m just trying to give you a starting point and make it clear that you can <\/em><\/strong>use more than one paradigm in your project, without having to mix them, and well structured  namespaces will allow you to keep it all separate.<\/p>\n\n\n\n
Assets\/pixelfat\/CandySmushSega\/Game\/Model             <-- Game as a Peer\nAssets\/pixelfat\/CandySmushSega\/Application\/Game\/Model <-- Game inside Application (tightly coupled)\nAssets\/pixelfat\/CandySmushSega\/Model\/Game             <-- Feature first, mixed app & game model\nAssets\/pixelfat\/CandySmushSegaGame\/Model              <-- Split root - CandySmushSegaGAME\nAssets\/pixelfat\/CandySmushSega\/Core\/Game\/Model        <-- Context-driven (ergh.. 'core')\nAssets\/pixelfat\/CandySmushSega\/MatchThree\/Model       <-- Vertical Slice (my preference)<\/code><\/pre>\n\n\n
There’s loads of ways to do this, and none of them break the paradigm so use the one that makes sense to you, the project scope and your team.<\/em><\/em><\/p>\n\n\n
I’ve used this approach for many years and it works beautifully with domain-based thinking – your game logic doesn\u2019t even bleed into your UI or how you present that game to the user at all. Instead, you\u2019re building clear architectural lanes, and namespaces give you the signs and road markings.<\/p>\n\n\n\n
OK so where do I put my binary assets, Mr. Fancy Pants?<\/h3>\n\n\n\n
I want to be very clear that as with any software project, there’s no one solution that fits all. But if you use this way of separating concerns and using namespaces which reflect your directory structure, then you can do the same with assets!<\/p>\n\n\n\n
<\/span><\/figure><\/div>\n\n\n\n
For example, what if I wanted to keep my application and game assets completely <\/em>separate? I tend to put all of my binary assets in a \/Source<\/code> folder, then I can split that further down into prefabs, materials, shaders and so on. But it’s all one project, so I risk mixing the game assets which should be structured clearly for our 3D artists to manage, with the application graphics which our graphic artists will want to manage. So I have a source folder in the game which has a complete set of all required assets, then another in my application layer containing the customized assets I want to use for this <\/em>application of the game (see what I did there?).<\/p>\n\n\n\n
Your game isn’t one thing, it’s a series of products, combined<\/h5>\n\n\n\n
Let’s consider off-the-shelf solutions, games we buy from the asset store and we want to use them to make some quick cash or meet a clients feature requirement. In any similar situation, we’d simply buy that asset, drop it into \/Assets, reference it in our application, and start customizing the assets to match our design. So, why not follow that pattern and treat our game and application as two distinct products; one consuming the other, just as we described earlier…<\/p>\n\n\n\n
Think of the game as a plugin your application consumes.:<\/p>\n\n\n
    \n
  • The application owns state and orchestration. it contains the variations of the game resources needed for its version of the game.<\/li>\n\n\n\n
  • The game just plugs in to be run, because it’s the App’s content<\/em>. It contains a complete set of assets needed to use it.<\/li>\n<\/ul>\n\n\n
    Assets\/pixelfat\/CandySmushSega\/Application\/CandySmushSegaApp.cs <-- only required component in the scene, sets the current state\nAssets\/pixelfat\/CandySmushSega\/Application\/Scripts\/UI <-- UI instantiates and disposes of panel prefabs\nAssets\/pixelfat\/CandySmushSega\/Application\/Scripts\/UI\/Panels <-- panels are components attached to prefabs in source\/prefabs\/UI\/...\nAssets\/pixelfat\/CandySmushSega\/Application\/Scripts\/Model <-- data classes that need to be passed around or consumed\n\nAnd our binary assets sit in our Source folder..\n\nAssets\/pixelfat\/CandySmushSega\/Application\/Source\/Prefabs\/GameTheme\/Space\/Gems\nAssets\/pixelfat\/CandySmushSega\/Application\/Source\/Prefabs\/GameTheme\/Bugs\/Gems\nAssets\/pixelfat\/CandySmushSega\/Application\/Source\/Prefabs\/UI\/Menus\nAssets\/pixelfat\/CandySmushSega\/Application\/Source\/Textures\/Icons<\/code><\/pre>\n\n\n\n
    And our game, now looks like this…<\/p>\n\n\n\n
    Assets\/pixelfat\/CandySmushSega\/Game\/CandySmushSegaGame.cs <-- the entry point of our game asset, maybe even a prefab we just instantiate\nAssets\/pixelfat\/CandySmushSega\/Game\/Scripts\/LevelComponent.cs <-- A component or base class for an implemented level\nAssets\/pixelfat\/CandySmushSega\/Game\/Scripts\/GemComponent.cs <-- A component or class, part of our games data model\n\nAssets\/pixelfat\/CandySmushSega\/Game\/Source\/Prefabs\/Levels <-- Level prefabs with Level component attached and configured.\nAssets\/pixelfat\/CandySmushSega\/Game\/Source\/Prefabs\/Gems<\/code><\/pre>\n\n\n\n
    No One Rule<\/h3>\n\n\n\n
    How you name or structure these directories really doesn’t matter, we can even choose to simply use \/CandySmushSegaApp<\/code> and \/CandySmushSegaGame<\/code>. But crucially your namespaces <\/strong>still line up with the directories<\/strong>, so traversing both the code and asset structure is a breeze, we can use the correct pattern for each system, and we can switch out code and assets without worrying about breaking something somewhere else. 

    However you choose to do it, thinking about your project this way makes it much easier to approach the problem of keeping your code and project structured, easy to traverse and ring-fenced.<\/p>\n\n\n\n
    And as for never using MVC in games or mixing paradigms… Well, we didn’t, did we? But we could if we wanted to…<\/p>\n\n\n\n
    <\/span><\/figure><\/div>\n\n\n\n
    I use Unity to make just as many applications and installations as I do games and every one of them is just a single feature or set of features that is being presented to the user, by my application layer. Whether it’s a WebGL face-filter, a combat\/strategy game or an app for engineers to inspect vehicles on a production line. The same thinking has served me well with all of them, and no two are exactly the same.<\/p>\n\n\n\n
    Thanks for sticking around. \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":"
    If you\u2019ve been following along, you\u2019ll notice our domain-based folder structure naturally supports another important practice we should be enforcing in all C# projects: proper namespaces. A C# class\u2019s namespace should always closely mirror its file path so that at a glance, we know what context, file and domain we’re in, but in our case […]<\/p>\n","protected":false},"author":1,"featured_media":1302,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"editor_plus_copied_stylings":"{}","footnotes":"[]"},"categories":[21],"tags":[],"series":[23],"class_list":["post-964","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-unity-project-structure","series-unity-project-structure"],"blocksy_meta":[],"yoast_head":"\nPart 3: Structuring Projects with Namespaces, MVC and MVP - pixelfat.com<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/pixelfat.com\/home\/unity-namespaces-and-mvc\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Part 3: Structuring Projects with Namespaces, MVC and MVP - pixelfat.com\" \/>\n<meta property=\"og:description\" content=\"If you\u2019ve been following along, you\u2019ll notice our domain-based folder structure naturally supports another important practice we should be enforcing in all C# projects: proper namespaces. A C# class\u2019s namespace should always closely mirror its file path so that at a glance, we know what context, file and domain we’re in, but in our case […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/pixelfat.com\/home\/unity-namespaces-and-mvc\/\" \/>\n<meta property=\"og:site_name\" content=\"pixelfat.com\" \/>\n<meta property=\"article:published_time\" content=\"2025-08-20T06:06:19+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2025-09-01T07:27:35+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/pixelfat.com\/home\/wp-content\/uploads\/2025\/08\/both-is-good.gif\" \/>\n\t<meta property=\"og:image:width\" content=\"480\" \/>\n\t<meta property=\"og:image:height\" content=\"270\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/gif\" \/>\n<meta name=\"author\" content=\"admin\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"admin\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"8 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/unity-namespaces-and-mvc\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/unity-namespaces-and-mvc\\\/\"},\"author\":{\"name\":\"admin\",\"@id\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/#\\\/schema\\\/person\\\/36d03bd67f0b17363eac8e18408baae3\"},\"headline\":\"Part 3: Structuring Projects with Namespaces, MVC and MVP\",\"datePublished\":\"2025-08-20T06:06:19+00:00\",\"dateModified\":\"2025-09-01T07:27:35+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/unity-namespaces-and-mvc\\\/\"},\"wordCount\":1541,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/unity-namespaces-and-mvc\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/wp-content\\\/uploads\\\/2025\\\/08\\\/both-is-good.gif\",\"articleSection\":[\"Organising Unity Projects for Sanity and Scale\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/pixelfat.com\\\/home\\\/unity-namespaces-and-mvc\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/unity-namespaces-and-mvc\\\/\",\"url\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/unity-namespaces-and-mvc\\\/\",\"name\":\"Part 3: Structuring Projects with Namespaces, MVC and MVP - pixelfat.com\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/unity-namespaces-and-mvc\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/unity-namespaces-and-mvc\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/wp-content\\\/uploads\\\/2025\\\/08\\\/both-is-good.gif\",\"datePublished\":\"2025-08-20T06:06:19+00:00\",\"dateModified\":\"2025-09-01T07:27:35+00:00\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/unity-namespaces-and-mvc\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/pixelfat.com\\\/home\\\/unity-namespaces-and-mvc\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/unity-namespaces-and-mvc\\\/#primaryimage\",\"url\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/wp-content\\\/uploads\\\/2025\\\/08\\\/both-is-good.gif\",\"contentUrl\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/wp-content\\\/uploads\\\/2025\\\/08\\\/both-is-good.gif\",\"width\":480,\"height\":270},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/unity-namespaces-and-mvc\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Part 3: Structuring Projects with Namespaces, MVC and MVP\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/#website\",\"url\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/\",\"name\":\"pixelfat.com\",\"description\":\"Real-time & Interactive Dev by Dan Turner\",\"publisher\":{\"@id\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/#organization\",\"name\":\"pixelfat.com\",\"url\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/wp-content\\\/uploads\\\/2025\\\/08\\\/Header-White-on-trans.png\",\"contentUrl\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/wp-content\\\/uploads\\\/2025\\\/08\\\/Header-White-on-trans.png\",\"width\":2101,\"height\":511,\"caption\":\"pixelfat.com\"},\"image\":{\"@id\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/#\\\/schema\\\/logo\\\/image\\\/\"}},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/#\\\/schema\\\/person\\\/36d03bd67f0b17363eac8e18408baae3\",\"name\":\"admin\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/7f85c496320acd1d4b4be51019ef800d40574f3da5829fd58da102b8b9ffc834?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/7f85c496320acd1d4b4be51019ef800d40574f3da5829fd58da102b8b9ffc834?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/7f85c496320acd1d4b4be51019ef800d40574f3da5829fd58da102b8b9ffc834?s=96&d=mm&r=g\",\"caption\":\"admin\"},\"sameAs\":[\"https:\\\/\\\/pixelfat.com\\\/home\"],\"url\":\"https:\\\/\\\/pixelfat.com\\\/home\\\/author\\\/webadmin\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Part 3: Structuring Projects with Namespaces, MVC and MVP - pixelfat.com","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/pixelfat.com\/home\/unity-namespaces-and-mvc\/","og_locale":"en_US","og_type":"article","og_title":"Part 3: Structuring Projects with Namespaces, MVC and MVP - pixelfat.com","og_description":"If you\u2019ve been following along, you\u2019ll notice our domain-based folder structure naturally supports another important practice we should be enforcing in all C# projects: proper namespaces. A C# class\u2019s namespace should always closely mirror its file path so that at a glance, we know what context, file and domain we’re in, but in our case […]","og_url":"https:\/\/pixelfat.com\/home\/unity-namespaces-and-mvc\/","og_site_name":"pixelfat.com","article_published_time":"2025-08-20T06:06:19+00:00","article_modified_time":"2025-09-01T07:27:35+00:00","og_image":[{"width":480,"height":270,"url":"https:\/\/pixelfat.com\/home\/wp-content\/uploads\/2025\/08\/both-is-good.gif","type":"image\/gif"}],"author":"admin","twitter_card":"summary_large_image","twitter_misc":{"Written by":"admin","Est. reading time":"8 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/pixelfat.com\/home\/unity-namespaces-and-mvc\/#article","isPartOf":{"@id":"https:\/\/pixelfat.com\/home\/unity-namespaces-and-mvc\/"},"author":{"name":"admin","@id":"https:\/\/pixelfat.com\/home\/#\/schema\/person\/36d03bd67f0b17363eac8e18408baae3"},"headline":"Part 3: Structuring Projects with Namespaces, MVC and MVP","datePublished":"2025-08-20T06:06:19+00:00","dateModified":"2025-09-01T07:27:35+00:00","mainEntityOfPage":{"@id":"https:\/\/pixelfat.com\/home\/unity-namespaces-and-mvc\/"},"wordCount":1541,"commentCount":0,"publisher":{"@id":"https:\/\/pixelfat.com\/home\/#organization"},"image":{"@id":"https:\/\/pixelfat.com\/home\/unity-namespaces-and-mvc\/#primaryimage"},"thumbnailUrl":"https:\/\/pixelfat.com\/home\/wp-content\/uploads\/2025\/08\/both-is-good.gif","articleSection":["Organising Unity Projects for Sanity and Scale"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/pixelfat.com\/home\/unity-namespaces-and-mvc\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/pixelfat.com\/home\/unity-namespaces-and-mvc\/","url":"https:\/\/pixelfat.com\/home\/unity-namespaces-and-mvc\/","name":"Part 3: Structuring Projects with Namespaces, MVC and MVP - pixelfat.com","isPartOf":{"@id":"https:\/\/pixelfat.com\/home\/#website"},"primaryImageOfPage":{"@id":"https:\/\/pixelfat.com\/home\/unity-namespaces-and-mvc\/#primaryimage"},"image":{"@id":"https:\/\/pixelfat.com\/home\/unity-namespaces-and-mvc\/#primaryimage"},"thumbnailUrl":"https:\/\/pixelfat.com\/home\/wp-content\/uploads\/2025\/08\/both-is-good.gif","datePublished":"2025-08-20T06:06:19+00:00","dateModified":"2025-09-01T07:27:35+00:00","breadcrumb":{"@id":"https:\/\/pixelfat.com\/home\/unity-namespaces-and-mvc\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/pixelfat.com\/home\/unity-namespaces-and-mvc\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/pixelfat.com\/home\/unity-namespaces-and-mvc\/#primaryimage","url":"https:\/\/pixelfat.com\/home\/wp-content\/uploads\/2025\/08\/both-is-good.gif","contentUrl":"https:\/\/pixelfat.com\/home\/wp-content\/uploads\/2025\/08\/both-is-good.gif","width":480,"height":270},{"@type":"BreadcrumbList","@id":"https:\/\/pixelfat.com\/home\/unity-namespaces-and-mvc\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/pixelfat.com\/home\/"},{"@type":"ListItem","position":2,"name":"Part 3: Structuring Projects with Namespaces, MVC and MVP"}]},{"@type":"WebSite","@id":"https:\/\/pixelfat.com\/home\/#website","url":"https:\/\/pixelfat.com\/home\/","name":"pixelfat.com","description":"Real-time & Interactive Dev by Dan Turner","publisher":{"@id":"https:\/\/pixelfat.com\/home\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/pixelfat.com\/home\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/pixelfat.com\/home\/#organization","name":"pixelfat.com","url":"https:\/\/pixelfat.com\/home\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/pixelfat.com\/home\/#\/schema\/logo\/image\/","url":"https:\/\/pixelfat.com\/home\/wp-content\/uploads\/2025\/08\/Header-White-on-trans.png","contentUrl":"https:\/\/pixelfat.com\/home\/wp-content\/uploads\/2025\/08\/Header-White-on-trans.png","width":2101,"height":511,"caption":"pixelfat.com"},"image":{"@id":"https:\/\/pixelfat.com\/home\/#\/schema\/logo\/image\/"}},{"@type":"Person","@id":"https:\/\/pixelfat.com\/home\/#\/schema\/person\/36d03bd67f0b17363eac8e18408baae3","name":"admin","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/7f85c496320acd1d4b4be51019ef800d40574f3da5829fd58da102b8b9ffc834?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/7f85c496320acd1d4b4be51019ef800d40574f3da5829fd58da102b8b9ffc834?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/7f85c496320acd1d4b4be51019ef800d40574f3da5829fd58da102b8b9ffc834?s=96&d=mm&r=g","caption":"admin"},"sameAs":["https:\/\/pixelfat.com\/home"],"url":"https:\/\/pixelfat.com\/home\/author\/webadmin\/"}]}},"_links":{"self":[{"href":"https:\/\/pixelfat.com\/home\/wp-json\/wp\/v2\/posts\/964","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/pixelfat.com\/home\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/pixelfat.com\/home\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/pixelfat.com\/home\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/pixelfat.com\/home\/wp-json\/wp\/v2\/comments?post=964"}],"version-history":[{"count":37,"href":"https:\/\/pixelfat.com\/home\/wp-json\/wp\/v2\/posts\/964\/revisions"}],"predecessor-version":[{"id":1366,"href":"https:\/\/pixelfat.com\/home\/wp-json\/wp\/v2\/posts\/964\/revisions\/1366"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/pixelfat.com\/home\/wp-json\/wp\/v2\/media\/1302"}],"wp:attachment":[{"href":"https:\/\/pixelfat.com\/home\/wp-json\/wp\/v2\/media?parent=964"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/pixelfat.com\/home\/wp-json\/wp\/v2\/categories?post=964"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/pixelfat.com\/home\/wp-json\/wp\/v2\/tags?post=964"},{"taxonomy":"series","embeddable":true,"href":"https:\/\/pixelfat.com\/home\/wp-json\/wp\/v2\/series?post=964"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}