Last post Aug 28, 2010 06:14 AM by DigiMortal
Aug 20, 2010 11:01 AM|rbkpro|LINK
Started in middle of a new project. Our design architecture uses an n-tier (not MVC - no controllers) structure with Presentation, Data, Business and Service tiers. However the lead analyst has the majoriety of code all in the Business tier claiming it
all contains Business logic. Our data tier is nothing more than a single .dbml model of the primary database to support all of the Linq queries in the Business tier. To my mind Linq queries and classes they use are data access and belong in the data tier
but our lead analyst says they contain business logic therefore have to be in business layer.
Aug 20, 2010 11:47 AM|ketan_al|LINK
Please refer following
hope this helps
Aug 24, 2010 03:00 AM|jacobzhang|LINK
1) Linq contains linq to object, linq to sql, linq to xml, and so on.
2) If it's a big database, I suggest you use ado.net instead of linq, because linq to sql efficency is bad. If it's a small database (e.g. personal website, small business), your lead is right.
3) Linq can be used in BLL tier.
Aug 27, 2010 02:16 PM|rbkpro|LINK
Thanks! What would you call a big database for converting to ado.net?
Aug 28, 2010 06:14 AM|DigiMortal|LINK
I don't agree that LINQ To SQL is slower than ADO.NET for big database. Before selecting your mapping technique (Linq To SQL, Entity Framework, NHibernate, etc) try to use these technologies on some big test database that is correctly indexed and tuned.
If your preferred mapping technology does not give you good results then check out what is the SQL it generates and executes. And if it is needed then tune your queries.
Mapping technologies always have cost calculated in performance. It is balancing between the need for development time and server resources. If no mapping technology gives you expected results then you must write your own data layer manually. It has usually
the best performance but it is not easy piece to write (to write good data layer you must have strong experiences on business applications development, specially on DAL, object runtimes etc).
LINQ To SQL and Entity Framework use their own context object that enables querying the database. You have to be careful when writing queries because you have to also look at database if there is need for additional indexes. Also you have to careful because
there may be better way to get the results you need so the execution of your query needs less resources. The point is - although you can write whatever queries you like against context you still have to understand what is going on in database side.
Where to place your queries? Well, usually I use interfaces in my core library that define data access rules. Data access library (or libraries) are plugged to my application using some DI/IoC container. Basically my business layer has no idea where data
comes from - all it knows are these interfaces. This way I can easily switch my data layer implementation without affecting the other layers of system.