Business Objects and Data Layer

Question

This site provided me with many useful answers, however after several hours of searching I did not find anything that specifically suits my needs. So here goes ...

The company I'm working on is in the process of designing a new level of business objects and a level of access to data - they will be placed in separate assemblies.

The problem is that it’s not easy for me to understand the interaction between these two levels - in particular, if DAL knows about BOL, I read a lot of articles that say that the order of dependencies should go something like this: this:

GUI / Presentation → BOL ---> DAL

But, as far as I see, DAL needs a reference to BOL in order to be able to "return" objects to the BOL level.

I am going to do an intermediate assembly between BOL and DAL, which will be basically a thin layer filled with interfaces to decouple the two DLLs, so this structure can use different DALs if necessary.

This led me to the idea of ​​introducing another thin layer with a bunch of interfaces that BOs implements, and then, when BOL calls the DAL interface, it passes it an object that implements one of these BO interfaces, and then DAL continues to populate the object. This removes all the dependencies between BOL and DAL — however, it’s hard for me to justify this, to be honest.

Ideally, we would like to use ORM, because it just removes the need to write CRUD materials, but our customers are in the habit of messing around with the column lengths in their database, and this is the reason for most of our errors today, using strongly typed DataTables. I heard that Linq2SQL also stores column lengths at compile time, but I'm not sure what NHibernate does or not (but I'm not sure that our database schema is designed enough for NHibernate, a trap for working with legacy systems).

So, any understanding of the relationship between BOL and DAL would be very welcome - sorry if the above is poorly written, if anyone needs clarification, I will gladly provide more detailed information.

Marlon

Answer 1

As I do this, BO expects a DataReader or DataContext or something back from the DAL, not the actual generated object. Then the task of the BO layer is taken and filled from the returned object. DAL does not return the completed BO back. The main thing to remember is that changing something in the BO layer should not cause problems for the DAL layer, but changing something in the DAL layer can cause problems for the BO layer.

A brief example of what I usually do

In layer BO

 FillData(){ DataReader dr = DataLayer.GetData("SomePropertyForAStoreProcedure"); If dr.Read(){ Property1 = dr.GetValue("Property1"); //So on and so forth } } 

In DAL

 DataReader GetData(String SPProperty){ } 

Answer 2

take a look at SubSonic http://subsonicproject.com/ , it makes most of the data access tedious for you, and it's easier than most ORMs

Answer 3

DAL needs a reference to BOL so that it can fill objects. What you do not want to have is a link or link from BOL to DAL - this causes the BOL to be bound to a specific database implementation. When you think about it, it makes sense. Your DAL knows the details of business objects down to the level of properties and how to retrieve their data from the database — of course, DAL is intrinsically closely related to BOL. So this link is ok. And if you think about it, then on the other side? Database. A “tight connection” comes from your object data to your database? Yes, it's pretty darn. The concept is not very significant even.

This is all a different direction where you need to separate. So yes, as long as there is no direct connection with DAL in BOL, you can change your data platform at any time.

There is not much point in creating interfaces for BOs and passing them to DAL in this scenario. However, sometimes you may need a different path. Typically, business objects do not need to know anything about how they are created or stored.

In practice, even with most ORMs, for example, creating a business level completely free of any persistence artifacts can become very difficult, sometimes it is not possible to be effective. Therefore, sometimes you have something too difficult to work with, although you may find that strictly eliminating the presence of any data in BOs leads to excessive complexity, which degrades rather than adds value.

If you feel that there is no better way and you need to save something from within BOL, create a simple interface so that DAL functionality can be passed to BOL. That way you can still exclude BOL from a specific database implementation.

Also, although this is a lot of work, if it is not a very simple application, I highly recommend that you add another layer between the user interface and BOL. The MVP (Model-View-Presenter) pattern is a general-purpose pattern to reduce communication between the main application and the user interface. There are many options for speakers, do not get too involved in specific details, just start with a simple MVP if you have never used it.

Templates are not so difficult, just the user interface is so confused that it may take at least a few basic iterations / applications before you feel that the code you write at any time systematically and methodically works to decouple the interface. Just keep working on it, start acquiring an arsenal of technology, and don’t get hung up on the fact that you actually haven’t reached a sharp, clean separation. Everything that you learn and can do it even makes a small contribution to creating a well-defined border in the user interface - this is a big step in the right direction.

Answer 4

The “right” approach will vary depending on the needs of the business. Honestly, there are many projects in which I feel that older ado style records take less time to develop and are easier to maintain than many of the ORMs. Take some time to determine what your needs are and remember that development time and maintainability are development goals that also need to be weighed correctly.

Answer 5

It also depends on which / which library / ORM (Object-Relational Mapper) you are using. When using (good) ORM, DAL must be very remote because it is almost completely hidden by ORM; however, best practices dictate that even then for medium to large size applications, you should introduce another layer between BOL and ORM, usually DTO (Data Transfer Objects). DTOs can also be used without ORMs, since they are just dumb objects defined in a separate library, and DALs can be responsible for their preservation (converting them from / to database structures), while BOLs can query DALs and get these objects.

Decoupling of layers can be achieved in various ways, most often through interfaces and / or MEF or another DI / IOC framework. Any such method achieves more than sufficient isolation with effective use.

In addition, depending on the technology used, as Sisyphus said, one of the multi-level architectural patterns will help to separate the problems: MVC, MVP, MVVM, etc. I personally recommend MVVM with WPF (desktop) or Silverlight (web), but I’m very biased, that is, I love them both to death :)

Answer 6

These are my findings
1. Use interfaces
2. Use DTO [data transfer objects] between DAL and BLL
3. Divide the BLL into two,
a. BLL
b. Service Layer
4. Use an Inversion of Control (IoC) container to keep communications as low as possible.