If the user interface components are ever submitted to the Business Logic assembly for binding

Question

Recently, I was provided with a code base that does a few things that I am slightly different from how I usually do them.

The main difference is that it seems to pass elements (for example, drop-down list management) to the level of business logic (in this case, a separate project, but still in the same solution), where there is a link to business data.

My natural approach should always be to process the information needed for the user interface and link it.

I'm struggling to match the first method with any of the standard templates, but this may be less than the idea of ​​what it does before the actual implementation.

Has anyone ever come across this type of architecture before? If so, can you explain the benefits?

The solution is an ASP.Net website. Thanks.

Thanks,

Answer 1

I would say that this is a bad architecture, as the original developer closely linked the business logic with the presentation layer. If you want to switch from web forms to, say, MVC, you will have to reorganize pieces of your business layer, which should not be!

If at all possible, you should consider giving up site development in this way. In the meantime, you can at least start the decoupling process by dividing the logic a bit further. If, say, you have a BindDropDown(DropDownList ddl) method, divide the method into parts, so you have a GetDropDownData() method that returns your actual business object, and BindDropDown sets only DropDownList values. This way, at least, you can more easily get away from the tight link between presentation and business in the future.

Of course, if the site was already designed in this way (with a clear demarcation between the presentation layer, the intermediate layer of the presentation binding and the business layer), I could see what was becoming acceptable. However, it is not.

Answer 2

No, you should not pass user interface elements to the domain model for binding / populating.

Ideally, your domain model should be able to be used with Windows Forms / WPF / Silverlight / ASP.NET / MVC, which you will name.

Now I understand the idea that your business objects should know how to store and display themselves, etc. this is the holy grail of OO, but in practice it does not work well, since there are often dependencies (database middleware, user interface components, etc.) with functions that you do not want in your BO assembly, this greatly limits your reusablility .

Something you can do, although it gives your users the illusion that your BO knows how to make yourself, is to use extension classes (in a separate assembly to contain dependencies), something like ...

 public static class AddressUIExtensions { public static void DisplayAddress(this Address add, AddressControl control) { ... } } 

Then the API user can simply execute

 var ctrl = new AddressControl(); address.DisplayAddress(ctrl); 

but you still have physical separation.

Answer 3

Has anyone ever come across this type of architecture before? If so, can you explain the benefits?

The only advantage is the speed of development - in the short term; therefore, it is well suited for simple applications, proof of concept (PoC), etc.

Implementing the right abstraction usually takes a lot of time and brings complexity. Most of the time, this is what you really want, but sometimes an application can be created as a simple Drop PoC.

In such cases, it’s not so much that a room full of people sits down and discusses architectures for several hours and comes to the conclusion that linking in BL makes sense - usually it’s “whatever” the “fastest” call of developers based on speed .

Of course, this simple laziness or ignorance is likely to be the reason why it was used in other cases.

Answer 4

Your business level should return a model - a presentation model, which the user interface layer, in turn, will use to fill out the required period. There should not be anything to the business layer in terms of the components of the ui - period. It is so simple and so difficult and quick to rule.