In the "ASP.NET 2.0 Website Programming" book Marco uses 2 classes: ArticleDetails (DAL) and Article (BLL). I don´t understand why it´s necessary to have both classes, since they have almost the same properties. Why can´t the DAL select data from the DB and instantiate an Article object directly, instead of instantiating an ArticleDetails and sending this object to the BLL, that uses the ArticleDetails obtained from the DAL to instantiate an Article object?
That´s it. Why to use both ArticleDetails and Article classes?

Thanks.






Alexandre Vasconcellos

This is the issue of separation of tiers. People who prefer an absolute boundary between layers wouldn't want the DAL to have the ability to do anything with business rules. Since the BLL Article class can have extra business rules (I don't know if it does at this time), the idea was to make separate classes. The DAL is supposed to understand only Create, Read, Update, and Delete (CRUD).

<Personal_Opinion>
By the way, in a real world system you have a lot of other concerns and sometimes you have to break the clean separation of tiers in order to gain efficiency. The most obvious example is a stored proc that does a lot of work, other than simple CRUD. In an ideal multi-tier model it would be a sin to have any business awareness at all in the DB - your stored procs couldn't do any "heavy lifting", and all of the logical processing would have to be in the BLL.

I'm not a purist myself. I want a system that is both efficient and somewhat easy to maintain, so I typically have a slightly bastardized multi-tier model in the systems I develop :-)

It's also common is very large systems to have a bastardized model. If you have dozens of linked DB's and tables with combined keys of 4 or 5 columns, and one that's highly normalized, it's almost mandatory to break the rules of separation of tiers. You can still have some tiers and some separation, but the thought that 500 user programs are all going to share one DAL and BLL, and there will be no logical processing in the DB stored procs, and the DAL only does CRUD, just doesn't make much sense in this case.
</Personal_Opinion>

Eric

Eric, thank you for your information about this topic.
If you can help me about what I'm saying below I'd stay happy.

I'm developing a web site using 3-tiers:

- DAL: For example I have a ProcessDAL class that realizes CRUD operations (I use Enterprise Library 2.0 since my DAL will run againt SQL Server, Oracle or Firebird);

- BLL: For example I have a ProcessBLL. This class does not have much functionality. It has CRUD methods that forward the requests to the respective DAL methods. Sometimes I think these BLL classes aren´t necessary. They don´t do anything but forward requests. What do you think about it?

- PL: My web forms, that use ObjectDataSource components to call methods on the BLL classes.

I want to use both the same DAL and BLL layers using a WinForm UI. Because of it I'm using datatables in ASP.NET, even knowing that DataReader´s are much faster. What would you do in this case? Would you create methods on the DAL that return either a DataReader (for Web applications) or a DataTable (for WinForm apps), or would you create methods that could be used in both UI types?

Thanks








Alexandre Vasconcellos

>a DataReader (for Web applications) or a DataTable (for WinForm apps)...

You've framed the issue badly. Both WinForms and WebForms can use either DataReader or DataTable/DataSet. The question of which to use should be based on how you'll use the data, and not what type of presentation layer you'll have.

DataReader - always the best for "read only" unless you databind. It's possible to databind a readonly control to a datareader, but this isn't too common.

DataTable/DataSet - always the best for updating data, and for 2-way databinding

A third option you didn't mention is especially friendly to middle tier Business Logic Layers: Custom Collections. These are in-memory strongly typed containers of data that is very specific in purpose.

With all the noise about ASP.NET 2.0, a lot of people didn't realize that Windows Forms 2.0 also got some cool new features. The biggest addition is in Data Binding. Windows Forms can now support what I call automatic binding of UI elements to custom collections. This makes it much easier to design Windows programs because you can wire the controls to middle tier collection classes. It works better than ASP.NET because you don't have a limited page cycle that makes you re-bind constantly. You might like this book:
http://www.amazon.com/gp/product/032...lance&n=283155

This article is also good:
http://msdn.microsoft.com/msdnmag/issues/02/02/cutting/

You might also like Petzold's book on Windows Forms 2005, but I personally don't care for his style of not using Visual Studio to it's full potential. He's a bright man, but he doen't make a lot of real-world GUIs (his GUI designs tend to be rather odd in terms of usability), and he seems to prefer a tool I'd call "Visual Notepad" :-)

Windows Forms could always bind to custom collections that implement the proper interface, such as IList. But now databinding on Windows Forms has been taken to the next level, where is automatically binds to "Changed" events in controls.

You can also get my powerpoint slides and sample code that explain collections on .NET 1.1. I haven't updated it for 2.0 yet (generics), but the 1.1 basics are still applicable to 2.0.
http://www.ericengler.com/downloads/collectiondemos.zip

Eric

Eric,
your post helped me a lot.
Thanks.

Alexandre Vasconcellos