Hi,

I've been working through the book and looking at implementing the framework in a live project and I've hit a hitch with the 3 tier implementation.

At the foot of P51 it states that the UI should not reference the DAL, which is fine, but because all of the .Save methods are declared public in the in the EO classes, the UI has to contain a reference to the DAL or it won't compile as the DataContext is not visible.

Being a conscientious developer I wouldn't dream of abusing this by putting a quick hack in through the DAL from the UI but surely this breaks the intent of the 3 tier model?

I'm also having problems justifying why to use Stored Procedures over 'raw' Linq To SQL. The ORM just seems to add another layer of complexity, and another set of classes to handle while gaining a small advantage due to the strongly typed responses. Having said that, raw Linq To SQL seems similarly problematic, particularly update routines and update check policies.

Comments anyone?

Cheers,

Duncan

In good n-tier developement, the business logic (most of which should be in classes in your App_Code folder) should serve as the center of all operations. The only exception should be the DAL which is the go between for the business logic and the database. That's why the MVC framework was created, because the Controller essentially takes this function "imposing" a more object oriented architecture if you're unfamiliar with how to do it yourself.

It sounds like your business logic should handle the save operations. The UI layer should only execute calls in the business logic, ie "Hey, someone just clicked this save button, is anybody going to do anything about it. Once the event is raised, the event handler in the business logic should respond with the appropriate calls, in your case to save data to the database with the help of the DAL.

My understanding of LINQ, and I'm not using it so I may be very wrong, is that LINQ "smoothes" out the differences. Where .NET 2.0 created SqlDataSource and AccessDataSource and OracleDataSource, LINQ now essentially expands that power beyond databases to web services XML docs, etc. The advantage of LINQ is that it encapsulates the data access so that you don't have to care what it is when you use LINQ. Stored Procedures are completely different. They're procedures housed within the database itself for optimum application speed, so rather than writing DAL logic in your application and making it talk over the connection, your DAL just says execute Stored Procedure "X" and off it goes.

__________________
-------------------------

Whatever you can do or dream you can, begin it. Boldness has genius, power and magic in it. Begin it now.
-Johann von Goethe

When Two Hearts Race... Both Win.
-Dove Chocolate Wrapper

Chroniclemaster1, Founder of www.EarthChronicle.com
A Growing History of our Planet, by our Planet, for our Planet.

Thanks chroniclemaster1,

I know about good n-tier development, I've been writing it for 10 years, which is why I'm querying the approach in this book which forces a reference to the DAL to exist in the UI.

Actually, the business classes shouldn't be in the App_Code folder, they should be in separate Class Libraries so that the business object model can be used to power whatever UI you want (WinForms, WebService or ASP.NET) - the App_Code folder should only contain classes which are pertinent to the ASP.NET UI (Mebmership, Roles etc).

As you say, MVC was created to further separate Data, Business and UI elements, but that is not what this book is about, it's about a standard n-tier to Web development framework.

I won't remark on your comments about Linq, as you say you're not using it.

Any comments from anyone who's actually read the book?

Duncan