0

I'm building a MVC web app that consist of 3 projects. One for the GUI, one for the BusinessLogic and one for the Data access.

For my Data access I have a generated file by EF and therefore I have a generated class named "Customer". To make validation attributes for this class I need to make MetaDataType (which needs to be done in the same namespace and therefore I'm bound to do it in the DAL layer) - by doing this I refer to the Data access layer from my GUI which spoils the whole idea of splitting the project up, because that my GUI now refer both my DAL and BL layer. Is there anyhow I can keep my GUI and DAL layers seperated but still be abe to use Validation attributes like [Required] and so on?

Thanks in advance.

tereško
  • 58,060
  • 25
  • 98
  • 150
ebb
  • 9,297
  • 18
  • 72
  • 123

2 Answers2

2

That's what ViewModels are about. But that means you will have a new set of DTO's for the view-controller communication... Which is a good thing IMHO, since your views should not know anything about the real domain model.

Regarding all distinct ways of making your views communicate with the model, please take a look at this.

rsenna
  • 11,775
  • 1
  • 54
  • 60
  • Those "ViewModels" - should they be passed to my BL layer and "wrapped" into the EF generated classes? – ebb Dec 14 '10 at 19:45
  • No, viewmodels should be seen only by the views and the controllers - they are **not** part of your BL or DAL. Think of them as data as the **user** sees it - which is probably quite different as the way as the same data is persisted at your domain model. – rsenna Dec 14 '10 at 19:47
  • What should I do if I want to pass one of my viewmodels to the BL? - Or maybe you normally dont use classes as parameter? – ebb Dec 14 '10 at 19:49
  • You should not do that. Again, that's not what viewmodels are about. BUT I have done something similar in the past (when I did not know anything about [persistence ignorance](http://thinkddd.com/glossary/persistence-ignorance/))... And what I did was creating **another** project, that only had DTOs (the entities with only properties and nothing else). This project was referenced by all 3 layers: UI, BL and DAL. (Hm and that's what @Nelson here is telling you to do btw.) – rsenna Dec 14 '10 at 19:59
  • So instead of using the generated classes from EF you created your own classes to be used in another project and then referenced by all the layers? – ebb Dec 14 '10 at 20:01
  • @ebb: That was a LONG time ago, and I was using NHibernate, not EF. But, again, it was pretty much what Nelson is telling you to do - so you should use his advice if you want to go that way... – rsenna Dec 14 '10 at 20:05
2

If you're using .NET 4 (EF 2) you can generate POCO entities in a separate class library that can be shared across projects. That won't require a dependency to the DAL. See my previous answer:

ASP.Net Layered app - Share Entity Data Model amongst layers

Especially 3. POCO templates, including how to move to separate project: http://blogs.msdn.com/adonet/pages/feature-ctp-walkthrough-poco-templates-for-the-entity-framework.aspx

Community
  • 1
  • 1
Nelson Rothermel
  • 9,436
  • 8
  • 62
  • 81
  • As I've commented at my answer, this may be practical, but it is completely against the concept of persistence ignorance - since you would be mixing UI with the domain model. But nobody is forced to be a DDD programmer, of course. – rsenna Dec 14 '10 at 20:09
  • @rsenna: Unless I'm mistaken, you still have persistence ignorance; that's the whole point of using POCO. As long as you have some other abstraction such as the Repository pattern to handle the database calls you can replace the whole database backend, maintaining your POCO entities. Sure, the POCO entities will no longer be generated by EF, but there is no dependency on EF so it doesn't matter. – Nelson Rothermel Dec 14 '10 at 21:44
  • The problem that I see is not technical but architectural - you are sharing the **same** entities across both DAL and UI. So the presentation is coupled to the same entities that are used for persistence - and I don't think this could be called "ignorance"... But, again, I have done that before, and would do again for simple systems, or heavily CRUD oriented. Anything but that I would go with viewmodels for the UI, and domain entities for the business and data access layers. – rsenna Dec 15 '10 at 12:05