Using LINQ to SQL make application development faster but dissolves the logical layers in the application. The data access layer and the business objects layers almost have no identity, they sit in the same dll. Does any one has an idea on how to develop an enterprise level application using LINQ to SQL. How do we cleanly separate the business object and the LINQ generated entities ? How would they communicate, how would data be transferred between our business objects and LINQ entities. Any article or any suggestions towards this would be greatly appreciate. Thanks.
We're using L2S for our next generation of software that manages our plant operations and related applications. This is for a $2.5B thin film solar company. We have built a clearly defined L2S based n-tier application framework.
We also created our own code generator to generate an application set of entities, a L2S set of entities, a business logic layer and data access layer. The L2S set of entities is for back-end use only. The application entities (which have no L2S plumbing built in) is for transferring data back and forth from application to server. We use WCF for application tier to server tier communication.
Our applications use WCF to call to the back-end businss logic layer for data processing. The business logic layer calls to our data access layer for low level Linq based data access. Our application entities get passed to and from our back-end. In the back-end, we have very efficient mapping that maps an application entity to each L2S entity.
Works very well for us.
Randy
You can get very far with L2S (as StackOverflow has proven), but IMHO Linq2SQL is not well suited (nor intended, I think) for "enterprise level applications".
Now that Entity Framework 4.0 has been released, you may want to consider going with EF instead. It supports POCO and will allow you do have a much nicer layered architecture.
Check out:
The ADO.NET Entity Framework
ADO.NET C# POCO Entity Generator
I recently ported a substantial code base from L2S to EF 4.0. Since EF now supports lazy-loading, you can have a very smooth transition from L2S to EF, leveraging the advanced features of EF only when you need them.
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 am designing a simple C# WCF service using ASP.NET 4.0 and hosted on IIS7, which will be used by .NET and Java web applications and desktop applications to extract data stored in various databases (both local and remote). I am starting to learn how to use VS2010 and WCF after working for a few years on VS2005 and asp.net web services, so am somewhat of a noob to WCF but know a bit about web services and Visual Studio.
Does anyone have opinions on what the best approach would be in terms of project/class/file setup in Visual Studio 2010 to do this, seeing as how I want to maximize code re-use and minimize development time yet still have the ability to connect to the different databases? I have a WCF Service Application project for the service, and have generated a WCF Client to use for testing using svcutil.exe, but now I'm at the point where I need to start writing database access layer code (or "model" code for MVC if that's the design route I need to go down).
Any help appreciated, thanks!
Each of the databases will have their set of nuisances while integration. The first thing you need to start with would be to design your model in more of OO (Object Oriented) fashion than relation DB way. Once such a model is created, you need to implement mapper layer/classes that would map data from a relational form to a OO format. Then for each DB you need to write some data access code. The amount of code you write for data access may well depend upon the tools\technologies you use. You could look into Entity Framework or NHibernate or other such ORMs to decrease the code required to access data. But keep in mind these ORM mappers may require their own set of tweaks to work well with MySQL, Oracle, SQL Server.
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 currently have an asp.net web application which is using seperate assemblies for the data access, the business logic,
entity objects, and the web user interface. The data access was created using Microsoft's Data Access Application Block
compilied as a .NET 2.0 assembly. Stored procedures were used for the actual moving of data in and out of the database
(SQL 2005).
I would like to update this application to a take advantage of the new features of .NET 3.5 such as Linq, data entities,
etc. What would be the best approach to make this happen?
I was doing some research about this topic and I found this article very useful.
http://blogs.msdn.com/dsimmons/archive/2008/05/17/why-use-the-entity-framework.aspx
Obviously, .net 3.5 has lots of new features if you compare to 2.0. one of them as you stated Linq(to SQL and to XML). which enables you to write strongly-typed language integrated queries. as you may know as well as querying your entities by using LINQ, you can query your collections and XML files.
Also you can use ADO.NET entity framework for mapping your database tables to classes. I am not sure about performance aspect. u might need to do some investigation about it.
dont forget to do your regression tests after you have developed new version of your application.
I know it is general information... I hope it helps.
Cheers
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