   Organizing Data Accessing Code (Database) In C#
  [font="Arial,"]I come from a PHP background doing it professionally for 5+ years now. I have always wanted to do web development in C# but hated WebForms and ASP.NET MVC was still not in a state where I really didn’t want to work with it back when I looked at it over a year ago. ASP.NET MVC is now in a pretty comparable state to how I work with PHP and my MVC framework, at least as far as it comes to the views and controllers. I have been working with NHibernate that past few days and I have to say that I like it so far. I have decided to take my upcoming PHP project and build it with ASP.NET MVC 3 along with using NHibernate as my backend as I feel I will be able to building a much more extendable system with all the features that C# has over PHP in OOP. One thing I want to make sure of is that the code that manages that data needs to be as flexible and expandable as possible so I just want to go through how I plan to setup this hierarchy (along with maybe one or two questions) and get peoples take on it. I also mentioned that I am using NHibernate just in case even though most of this architecture should be ORM independent.This first thing which is specific to NHibernate is that I am going to need to way to access NHibernate specific functionality, mainly accessing the NHibernate session object which allows me to interact with the database. This right now I see as a very simple singleton class (or maybe a static class) that has a property holding the NHibernate session object and maybe some basic methods.The next level is where I am going to handle the interaction with the actual data. From what I have read, it seems like using the repository pattern would be a perfect fit. I would basically create a repository class for each business object (usually 1 table in the database) and the single responsibility of that object would be for CRUD operation to the data. If I need to read, create, update, or delete any data from the database, it would be handled through the repository object.Now the next level is about storing the data and having the business logic that is performed on/with the data. This is one level that I am a little unsure about my approach since I have never designed this level in PHP the why I am think about doing now. This level is going to compose of 2 main groups and that is Data Transfer Objects (or DTOs) and Business Objects (or BOs). Now for each group of data (generally 1 table in a database), there is going to be an interface created that just defines the required fields/properties that are needed, no methods will be contained in this interface. From that interface, I will create a DTO and a BO that both implement that interface.[font="Arial,"] [font="Arial,"]Now my initial reaction was to have the BO object just have a field with the type of the DTO but thinking about it more, that then tightly ties the DTO to the BO and I wanted a solution where those two objects are not so tightly coupled together. This way with the interface requires more code (I have to define the properties in both the DTO and BO) but it does make the DTO and BO loosely coupled.One area of question for me is about when to pass/return the DTOs and when to pass/return the BOs. My gut reaction tells me to always map NHibernate to the DTOs, not BOs, and always pass around the DTOs when talking about parameters and return values. Then whenever I needed to perform business logic, I would convert my DTO into a BO. The way I would do this is that my BO would have a have a constructor that takes a parameter that is the type of my interface that both my DTO and BO implement as the only argument. Then I would be able to create my BO by passing it the DTO in the constructor (since both with implement the same interface, they both with have the same properties) and then be able to perform my business logic. I would then also have a way to convert a BO to a DTO. However, I have also seen where people seem to only work with BOs and only work with DTOs in the background where to the user, it looks like there are no DTOs.[font="Arial,"] [font="Arial,"]Another question I have with DTOs is that I keep hearing that they should be flatten object.  Does this mean that they should only contain basic values (int, bool, float, string, etc..) and not other DTOs?  [font="Arial,"] [font="Arial,"]Does my architecture even make any sense (please feel free to tell me it is complete crap if you think it is)?[font="Arial,"]What benefits/downfalls are there with this my architecture?[font="Arial,"]What benefits/downfalls are there with only passing around BOs?[font="Arial,"] [font="Arial,"]One thing that I am 99% sure with is that I want to be consistent as far as return/parameter types being passed/returned (then again as write this I guess I could just pass/return the interface type). I think it is easier to know that I am always passing/returning either DTOs or BO.That is basically it. Please let me know what you think about this architecture. Have I missed any core levels? Do I have any unnecessary levels? What changes would you make to the levels I have? This is a personal project which gives me the benefit of no deadlines which means I want the code quality to be as good as it can be. I hope to one day release this project as an open source project (or at least the core of the system as open source with maybe pay for modules) but I don't want it to be like a lot of other open source projects where is it a great product for the users of the product but for programmers, dealing with the code in a nightmare (quite of a few of those in the open source PHP realm).Remember that the focus is about high flexibility and extendibility.Please let me know if you need anything explained further to understand what I am trying to explain.  If need being I can probably come up with some code examples.   
[font="Arial,"]I come from a PHP background doing it professionally for 5+ years now. I have always wanted to do web development in C# but hated WebForms and ASP.NET MVC was still not in a state where I really didn’t want to work with it back when I looked at it over a year ago. ASP.NET MVC is now in a pretty comparable state to how I work with PHP and my MVC framework, at least as far as it comes to the views and controllers. I have been working with NHibernate that past few days and I have to say that I like it so far. I have decided to take my upcoming PHP project and build it with ASP.NET MVC 3 along with using NHibernate as my backend as I feel I will be able to building a much more extendable system with all the features that C# has over PHP in OOP. One thing I want to make sure of is that the code that manages that data needs to be as flexible and expandable as possible so I just want to go through how I plan to setup this hierarchy (along with maybe one or two questions) and get peoples take on it. I also mentioned that I am using NHibernate just in case even though most of this architecture should be ORM independent.This first thing which is specific to NHibernate is that I am going to need to way to access NHibernate specific functionality, mainly accessing the NHibernate session object which allows me to interact with the database. This right now I see as a very simple singleton class (or maybe a static class) that has a property holding the NHibernate session object and maybe some basic methods.The next level is where I am going to handle the interaction with the actual data. From what I have read, it seems like using the repository pattern would be a perfect fit. I would basically create a repository class for each business object (usually 1 table in the database) and the single responsibility of that object would be for CRUD operation to the data. If I need to read, create, update, or delete any data from the database, it would be handled through the repository object.Now the next level is about storing the data and having the business logic that is performed on/with the data. This is one level that I am a little unsure about my approach since I have never designed this level in PHP the why I am think about doing now. This level is going to compose of 2 main groups and that is Data Transfer Objects (or DTOs) and Business Objects (or BOs). Now for each group of data (generally 1 table in a database), there is going to be an interface created that just defines the required fields/properties that are needed, no methods will be contained in this interface. From that interface, I will create a DTO and a BO that both implement that interface.[font="Arial,"] [font="Arial,"]Now my initial reaction was to have the BO object just have a field with the type of the DTO but thinking about it more, that then tightly ties the DTO to the BO and I wanted a solution where those two objects are not so tightly coupled together. This way with the interface requires more code (I have to define the properties in both the DTO and BO) but it does make the DTO and BO loosely coupled.One area of question for me is about when to pass/return the DTOs and when to pass/return the BOs. My gut reaction tells me to always map NHibernate to the DTOs, not BOs, and always pass around the DTOs when talking about parameters and return values. Then whenever I needed to perform business logic, I would convert my DTO into a BO. The way I would do this is that my BO would have a have a constructor that takes a parameter that is the type of my interface that both my DTO and BO implement as the only argument. Then I would be able to create my BO by passing it the DTO in the constructor (since both with implement the same interface, they both with have the same properties) and then be able to perform my business logic. I would then also have a way to convert a BO to a DTO. However, I have also seen where people seem to only work with BOs and only work with DTOs in the background where to the user, it looks like there are no DTOs.[font="Arial,"] [font="Arial,"]Another question I have with DTOs is that I keep hearing that they should be flatten object.  Does this mean that they should only contain basic values (int, bool, float, string, etc..) and not other DTOs?  [font="Arial,"] [font="Arial,"]Does my architecture even make any sense (please feel free to tell me it is complete crap if you think it is)?[font="Arial,"]What benefits/downfalls are there with this my architecture?[font="Arial,"]What benefits/downfalls are there with only passing around BOs?[font="Arial,"] [font="Arial,"]One thing that I am 99% sure with is that I want to be consistent as far as return/parameter types being passed/returned (then again as write this I guess I could just pass/return the interface type). I think it is easier to know that I am always passing/returning either DTOs or BO.That is basically it. Please let me know what you think about this architecture. Have I missed any core levels? Do I have any unnecessary levels? What changes would you make to the levels I have? This is a personal project which gives me the benefit of no deadlines which means I want the code quality to be as good as it can be. I hope to one day release this project as an open source project (or at least the core of the system as open source with maybe pay for modules) but I don't want it to be like a lot of other open source projects where is it a great product for the users of the product but for programmers, dealing with the code in a nightmare (quite of a few of those in the open source PHP realm).Remember that the focus is about high flexibility and extendibility.Please let me know if you need anything explained further to understand what I am trying to explain.  If need being I can probably come up with some code examples.Maybe I'm just tired, but I find your post rather extra-large. If anything, I can say that your design sounds way too complicated for a game.;[font="Arial,"][font="Arial,"]Another question I have with DTOs is that I keep hearing that they should be flatten object.  Does this mean that they should only contain basic values (int, bool, float, string, etc..) and not other DTOs?  No, not generally.[font="Arial,"] [font="Arial,"]Does my architecture even make any sense (please feel free to tell me it is complete crap if you think it is)?I understand what you mean; generally.[font="Arial,"]What benefits/downfalls are there with this my architecture?If implemented properly, it should allow a fair amount of flexibility if you need to present multiple sources through a unified service or if you need to swap out certain pieces.That said, it is a huge amount of overhead and complexity which I would consider overkill in almost all scenarios. "flexible and expandable as possible" are pretty crappy requirements. They're often in conflict with success (read: shipping).[font="Arial,"]What benefits/downfalls are there with only passing around BOs?Less code to write means less oopsies. Less types means less translation/cognitive overhead/pain in consuming code. Though passing only business objects can be a little awkward/inefficient since consumers often don't need the whole BO, or need some flattened representation of 2+ of them.