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.
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.
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
I see a number of posts talk about rolling your own LINQ to SQL XML mapping file. Why would you do this instead of using SQLMetal or the designer built into studio? Is it because you want to work with your own POCOs?
If you use the designer then you have no control over the generated classes. While this may be alright for many applications, it's not appropriate for all.
Probably the biggest single advantage to using an external mapping is that it breaks your model's dependency on Linq to SQL, so you could (for example) take the exact same model classes and use them with Entity Framework or NHibernate. Projects or assemblies which need to use the model don't pick up an unwanted dependency on the System.Data.Linq assembly.
Other things you might want to do are:
Include validation logic or other complex logic in property setters;
Use virtual properties (for proxying);
Decorate existing properties with other attributes (i.e. serialization);
etc.
None of these things are possible with generated code. You can extend via partial classes, but that only lets you add members, not change existing ones. You can change the designer-generated code, obviously, but your changes will just get overwritten.
As I mentioned, many projects don't need these things, but many projects do, and if yours is one that does then you'll outgrow the DBML designer and SqlMetal pretty quickly.
I am currently reading Pro Asp.Net MVC, and they are building all of their linq2sql entity classes by hand, and mapping them with the linq mapping attributes. However, everyone else I see (from google searches) talking about linq 2 sql seem to be using the visual designer for building all of their entities. Which is the preferred way to build l2s entities, and what are the advantages/disadvantages of each?
The only difference I have noticed so far, is I can't seem to do inheritance mapping when using the visual designer, although MSDN says I should be able to so I might just be missing it in VS 2010's interface. However, I'm not so sure I should use inheritance anyway as that could technically add additional joins when I don't need the sub table data.
As a PS, l2s will not be doing any modification of my schema, I will be generating schema changes manually and then replicating them in linq2sql.
Thanks,
We used the designer all the time. It indeed introduces an added step, every time you make a change to the schema you need to import the table into the designer again, but I think that effrot pales in comparison to the amount of code you need to write if you bypass the desginer.
Also note that the designer creates partial classes, you can create an additional file for the partial class that includes additional implementation details. That way, when the table gets refereshed in the designer, it leaves you additional code alone. We do this to add a lot of helper functions to the classes, and also to provide strictly typed enumerated properties that overlay the primitive integer FK fields.
It's true that inheritance would be very difficult to accomplish well, but I think if you need that sort of data layer, L2S may not be the best solution. I prefer to keep my data layer clean and simple, just using L2S to get the data in and out, and then pu more complicated logic in the business layer. If we really needed to do things like object inheritance in our data layer, I would probably explore a more advanced and complicated technology like EF
We've built our entire application framework backend using L2S. I developed most of the this. I started to use the DBML designer but I quickly realized this was a royal pain. Every schema change required a change to the table(s) in the designers. Plus, the entities created by the designer all get stuffed in a single class file, and didn't have all the functionality I wanted, like support for M2M relationships, and more. So, it didn't take long before I realized I wanted a better way.
I ended up writing my own code generator that generates the L2S entities the way I want them, and it also generates a "lightweight" set of entities that are used in the application layer. These don't have any L2S plumbing. The code generator creates all these entities, and other code, directly from a target database. No more DBML!
This has worked very well for us and our entities are exactly the way we want them, and generated automatically each time our database schema changes.
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.