Question

I need to know whether it is a right approach from an architecture perspective.

I am working on MVC project , i have a separate assembly for the data layer and another assembly for models. Both of these assemblies are referenced in MVC project.

Now a scenario has turned up where I need to have data annotation string from database in model assembly, is it fine to reference data layer in model assembly and fetch a string from the database or if there is a better approach to it.

Please suggest

Answer 1

As usual with design issues, the answer is “it depends” 🙂

I have one project where the exact same entities are used as models, and as data entities, so basically the same data annotations are used in the UI (ASP.NET MVC) and in the data layer (EF 4.3). It works. The upside is that it’s consistent all over the system (an Account object means the exact same thing everywhere), the downside is that any additional model logic, whether it’s database oriented (e.g. navigation properties) or UI oriented (e.g. FullName property for the Account class) will be mixed in the same place.

I have another project where the Models for the UI layer are completely separated from the data layer, communication via a management layer. It works. Here the upside is that each layer is very crisp, and its responsibilities are very well defined. However, the downside is that lots of the management code is plumbing code, yet not simple enough to be auto generated. Also, any change that, for example, adds a text field to an entity need to be changed in few more places. A not trivial remark is that communication between developers is somewhat hampered by the fact that there are a few “Account” classes (AccountViewModel, AccountEntity, AccountManager etc)

So, my point is, do whatever seems most consistent with your current architecture.