3

I have a Visual Studio solution with multiple projects.

I am not 100% settled about the project structure and its benefits.

For example: I have a Project called DOMAIN. Here I have several folders like:

DOMAIN
|
|_Repository
  |__Implementations
  |____|__OrderRepository.cs
  |____|__CustomerRepository.cs
  |__Contracts
  |____|__IOrderRepository.cs
  |____|__ICustomerRepository.cs
  SessionManager.cs
  Model
  |__Customer.cs
  |__Order.cs

QUESTION: Should the Model be separated from the Repository in an extra project?

If yes, WHY?

Taryn
  • 242,637
  • 56
  • 362
  • 405
Elisabeth
  • 20,496
  • 52
  • 200
  • 321

1 Answers1

4

If you strive for your application to be storage agnostic then yes. One way to do it is to have your model contain abstractions for your repositories, such as abstract classes or interfaces. Then you would have a separate project, which you could call something like data access layer (DAL), and it would hold a reference to your model project and implement the abstract repositories.

The benefits of this is a cleaner separation of responsibilities between your project (eg. your model project implements business logic and your DAL project knows the gory details about how to fetch data). Furthermore, this would allow you to implement two different DAL's, one targetting SQLServer and one targetting SqlLite for example.

Klaus Byskov Pedersen
  • 117,245
  • 29
  • 183
  • 222
  • was gonna post something very similar +1 – tQuarella Dec 30 '10 at 16:34
  • ok I could just swap the project with the DAL for sqlite and use a sqlserverdal. Sounds all ok therefore I marked it as solution, but with an ORM tool like Entity Framework your advice does not make sense right? I query a context via a LINQ-Provider and this can be sqlite/sqlserver/mysql etc... – Elisabeth Dec 30 '10 at 17:03
  • argh... I had an important typo haha. I HAVE already 2 Projects but the DAL has the implementation + contracts the MODEL has the entities... ok for the learning effect I move the interfaces to the MODEL although I like to keep the impl.+contracts together somehow ;-) – Elisabeth Dec 30 '10 at 18:36
  • @Lisa, keeping implementation and contracts together make your projects more tightly coupled and are preventing you from modularize your code efficiently. If anything, you should rather keep all your contracts separate from everything else. – Klaus Byskov Pedersen Feb 20 '11 at 20:48