I'm trying to design application that will have UI with database in the backend.
I will be using Linq-to-SQL as the database layer to update and insert.
Now I'm trying to find out the best practice to use in designing the project, suppose I have 2 tables in the DB (Customers, Orders)
Shall I depend on the generated Linq-to-SQL classes, or shall I still create classes for Customers, Orders?
Shall I wrap the generated Linq-to-SQL inside another class to add validations?
I hope my questions are clear.
L2S is in my opinion an excellent light-weight data access method. If you have control over the database and have limited application data processing logic it is often a good choice.
If you have a two-tier app with a UI communicating directly with the DB then you can depend on the L2S generated classes. If you have a multi tier app with a client communicating with e.g. a WCF service you probably need Data Transfer Objects.
Use the partial methods on the L2S classes for validation.
I think you should use other ORMs for better implementation DAL for example Entity Framework or Nhibernate this ORMs allow you Model First approach without attributes
and the validation logic you should separate in other classes for exmaple MyEntityValidator
And also good approach to use the Repository pattern this pattern allow doesn't depend on Data access EF or Nhibernate
and look at this Entity Framework and Repository
Related
How tightly can the ORM data classes generated by LINQ to SQL be integrated with the Model layer in MVC? Could these ORM data classes act directly as the model, if so, how would validation occur as it is usually done in MVC 3 with DataAnnotations? It seems that it would be diffiult to add these to the generated classes.
Separation of Concerns suggests that the classes that make up your domain model shouldn't be dependant on the technology that's used to implement your Data Access Layer, so I make every effort to ensure that they're not propogated through the UI.
If you use Entity Framework instead of Linq-to-SQL, you can use the POCO generator instead of EF's default EntityObjects. While these are still generated from the EF database model, you can replace the data access implementation but retain the POCO's for your domain model.
LINQ will generate a set of classes from the SQL files. Should these be used directly, or should they be wrapped in another class so the model is not so dependent on the implementation?
You can do it either way. Generally I wrap the Linq to SQL classes in a repository, but if the app is small you can use the repository methods directly.
If the app is larger you can add a business layer.
If you actually need to abstract from your sql database's model, then Linq-To-Sql is probably the wrong choice. Sure, you can make it work (but that isn't what it was made for).
If you need that level of abstraction, you will want to move on to a more "enterprisey" ORM like Entity Framework. They require more configuration, which is used to specify the more intricate mappings that allow your object model and database model to not resemble each other,
On the other hand, if this is overkill then use Ling to Sql. It's simple and it's easy, as long as you can stick with its simplified approach to mappings.
I think it's fine to use the generated model classes directly in your business and presentation tiers - however, I would definitely encapsulate data access for those entities inside a repository pattern of some description (GetOne(), Save(), Search(), Delete() etc).
The main reason for doing so is to 'disconnect' query results before returning them to a calling layer, so that clients don't inadvertently execute queries directly against the database when they use LINQ on returned results. Eg, calling ToList() on an IQueryable<T> will return a local copy of the sequence that can be managed using plain LINQ to Objects.
It also promotes better separation of layers and less coupling, as clients will interact via interface methods on the repository, rather than use LINQ to SQL directly for data access, so if you do decide to chuck LINQ to SQL in favour of the Entity Framework (shudders), it's easier to do the refactoring.
The one exception I would make is when LINQ to SQL objects need to cross a service boundary, ie, sent as data transfer objects to or from a WCF service. In this case, I think it's a good idea to have a separate, light-weight object model that supports serialization - don't send your LINQ to SQL objects directly over the wire.
I'm building an application on top of a legacy database (which I cannot change). I'm using Linq to SQL for the data access, which means I have a (Linq to SQL) class for each table.
My domain model does not match with the database. For example, there are two tables named Users and Employees, and therefore I have two Linq to SQL classes named User and Employee. But in my domain model I'd like to have a User class which should contain some fields from either table (but I don't care about a lot of the other fields of these tables).
I'm not sure how I should design my repositories:
should the repositories perform the mapping between Linq to SQL classes (e.g. User, Employee) to the domain classes (User) and only return the domain classes to the application
or should my repositories return the Linq to SQL classes and leave the mapping to the caller
The first approach seems to make more sense to me, but is this the correct way to implement my repositories?
The purist (I try to stay pure) will tell you that your model represents your data. And therefore, anything that needs to be persisted is done so only when needed through repositories. Also, when you have complex entities, you want to use a service to combine them. For example, User + Employee = UserEmployee entity that is only accessible through an IUserEmployeeService.
With those vague statements, you have an excellent opportunity here.
Build an anti-corruption layer, which allows you to start moving off of the legacy DB at the same time.
This is an another chapter in the DDD playbook. An Anti-Corruption layer is used to interface with a legacy system using Facades, Translators, and Adapters to isolate the legacy DB with your pure Domain model.
Now, this may be a lot more work than you wanted. So, you have to ask yourself at this point:
Do I want to start the process of
moving off of this legacy DB, or will
it remain for the life of the
application?
If your answer is you can start migrating, then model your actual domain the way you want it. Persist it with normal repositories and services. Have fun designing it the way YOU want it stored. Then, use the services of the aggregate roots to reach into the anti-corruption layer and pull out the entities, store/update them locally, and translate into your domain's entities.
If the answer is that the legacy DB will remain for the life of the project, then your task is much easier. Use your domain's services (e.g. UserEmployeeService) to reach into the anti-corruption's UserFacade and EmployeeFacade (similar to a "Remote Service" concept).
Within the Facades, access the legacy db using the Adapters (e.g. LegacyDbSqlDatabase) to get a raw legacyUser(). The next step would be to use an UserTranslator() and EmployeeTranslator() mapper that converts the legacy user data into your actual domain's version of the User() entity, and return it from the UserFacade back to your UserEmployeeService, where it is combined with the Employee entity that came from the same place.
Whoa, that was a lot of typing...
With your Adapters and Facades of your Anti-Corruption layer, you can do your Linq-to-Sql or whatever you want to do. It doesn't matter because you have completely isolated the legacy DB/system away from your nice and pure Domain - your domain that has its own version of User() and Employee() entities and value objects.
DDD and Linq To SQL don't go together very well because the generated classes are not meant to deviate significantly from your DB table structure. You'll have to either map your classes in a way that makes working with Linq to SQL a pain or just live with a non-ideal object model.
If you really want to utilize DDD and the repository pattern go for Entity Framework or even better NHibernate.
I am working on a framework which will provide some basic functionality for a number of applications which our company is going to develop.
The framework will come with a basic database schema which will support this functionality.
Developers using the framework will be expected to extend the database schema with their own tables. Future versions of the framework will be shipped with update scripts to make any changes required.
What do you think the best way of accessing the database would be - both from within the framework and in the application itself?
I'd like to use either LINQ-to-SQL or the Entity Framework.
Taking LINQ-to-SQL, for example, I guess I could distribute a DBML file with the framework, allowing the application developer to extend it and provide a reference to the data context back to the framework?
Although it presents some new details, this is still just a versioning issue.
As you develop your system, modifications to the database must be versioned along with modifications to the code. Updates to your system should be an executable package including those database scripts and your data access assembly.
Users that wish to upgrade to the next/latest version must apply the package, which will execute all the database scripts to update the database, and replace the assembly that contains your data access layer. You may want to consider making your DAL a separate assembly for distribution purposes. You could use dependency injection to plug your DAL into your core system.
Depending on the complexity of the system, my fallback would be LINQ to SQL. It performs better overall and is simple to implement. If you expect your object model to get fairly complex, and performance is not a major factor, you may want to go with EF now rather than having to switch later. That's a cost-benefit analysis between performance, complexity, and ease of development.
HTH
I hope that you're using MS Sql in the back-end (though you are if you have Linq To SQL as an alternative).
I have some experience using L2S and some using Entity Framework. In my opinion EF is the better choice because it gives you a better approach towards OR/M and more control over the database objects.
It has full support for LINQ and also for Entity SQL which will give you more power when you need to write complicated queries.
Do NOT think about using EF with MySQL. More about that here
In the NerdDinner example they use a repository pattern to decouple the business from the data layer. But then they use the Linq to SQL generated classes (Dinner specifically) as the entity class used throughout the project. So how decoupled is that really? It’s not like you could easily exchange Linq-to-SQL.
On my last project I created a separate entity class that I populated with left/right in the linq query because I found that even if you use a partial of the linq generated you cannot populate any additional fields that you add at query time.
LINQ to SQL is strongly tied to the database schema, which is why I wouldn't use it. I'd use Entity Framework instead, as it permits a mapping between the conceptual and logical models.