Hi,

currently I am building an app which needs to be accessible from a windows UI and from a web UI. But I am uncertain if I should use adapter or selfservicing with this in mind. From what I think, I should use adapter. I think this because the WinUI and the WebUI tiers need to address the same business logic and with adapter you can achieve this. But can I do this with SelfServicing aswell? What if I where to put the BL inside the entities and use these in both my projects (WinUI and WebUI)... Will I then be using the same BL?

I think this question originates from my lack of knowledge of tier design. From what I currently understand is that you should atleast go for three-tier design (UI, DAL, DS), as to put data access in the UI, would make it spagetti code and not reusable.

LLBLGen does this three-tier design for me: it can generate a DAL for me, which I can use in the UI. However, there is also business logic to implent. This can be done in the UI if you only have one UI. If you would have more then one UI, eg. WinUI and WebUI, you do not know if the BL is implemented the same in both UI's and you are not reusing the business logic. I think (am I right?) this is the main reason for LLBLGen to suggest to put validation in the DAL = in the entities. Now you can reuse and persist the same BL in the UI's, as both are using the same entities.

From what I see, selfservicing is perfectly usable in this scenario. If you where to choose for adapter in this scenario, you would only make life harder for yourself.

But there is another scenario... if I would like, for some reason I can't think of (do you know any?), to put the DAL (incl. BL) on a different machine then the UI, I would have to go to a four-tier design: UI, BL, DAL and DS. This is because I don't want the UI to ask everything (mainly BL) to the DAL using a network connection. When using an extra BL tier, the BL objects would become distributed objects, minimizing network latency. And finally, to implement this four-tier scenario we would have to use the adapter template.

So I think I can answer my own question (WinUI + WebUI -> SelfServicing = ok?): it depends where you put the DAL (incl. BL). If you place it on the same machine as the UI then use SelfServicing, otherwise choose adapter and build yourself the extra BL tier.

However, please note that what I just wrote as answer is something I don't know to be true. Please correct anything what is wrong in my part where I try to answer my own question.

Thank you for reading this long text and hopefully thank you for helping me out,

BC

You are correct. You should be fine using either selfservicing or adapter with a webUI and Winform UI since all of the elements are easily bound to the collections and entities. If you see yourself moving to a remoting scenario or any type of distributed scenario then you would want to use adapter.

BlueCell wrote:

LLBLGen does this three-tier design for me: it can generate a DAL for me, which I can use in the UI. However, there is also business logic to implent. This can be done in the UI if you only have one UI. If you would have more then one UI, eg. WinUI and WebUI, you do not know if the BL is implemented the same in both UI's and you are not reusing the business logic. I think (am I right?) this is the main reason for LLBLGen to suggest to put validation in the DAL = in the entities. Now you can reuse and persist the same BL in the UI's, as both are using the same entities.

I think you should put 100% of your Business login in the Entity classes.

And, you should put 100% of your UI code in the Win Form / Web Form.

This leaves the open question of, where do you put the code that queries the business layer and calls the task methods. I would normally say, put this in your Win Form / Web Form.

But, since you KNOW that you are doing more than one UI I would recommend a UIP (User Interface Process) layer. Create a project that has a class lib for each UI form (web/win) that you will have. In this lib you can do the querying of an calls to the business layer.

Once you do this your UI layers will reference the UIP project and you will have much less code duplication.

Of course, talk to 5 architechs and you might get 5 answers.

BOb

First of all: Thanks bclubb for answering that I am heading into the right direction. I just have to check so now and then to feel better I think

To pilotboba: What you suggest seems to me like a good solution. It's much like normal programming where you find yourself redoing much of the same stuff. You then build new objects in order to minimize this behavoir. Thank you for suggesting this to me.

However, to be honest, I must say I do not fully understand when to use adapter.

The LLBLGen documentation explains:

• When the project targets multiple database types and/or multiple schemas/catalogs. I perfectly understand this.
• When you are using a remoting scenario. Why would someone use a remoting scenario?
• When you do not need lazy loading scenarios in relation traversals. You still can navigate relations but you have to fetch the data up-front. I also understand this.
• When you need to extend the framework with derived classes. Why would someone extend the framework with derived classes? Could anyone give an example of when you do this?
• When you like to see persistence logic as a 'service', which is offered by an external object (broker, adapter). Frans wrote (http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=444) that some organisations demand that objects used in the GUI shouldn't be able to persist themselves so GUI developers have to use the BL classes to get things done which automatically avoids errors in teh application because some developer took a shortcut due to a deadline. What's the added value of not allowing the GUI to be able to persist itself?
• When you require fine grained database access control. Also understandable.

I would be very grateful I someone could answer this for me. Perhaps adding some to the documentation to make it even better?

TIA,

BC

I guess you understand most of the reasons of using the Adapter :> You understand more reasons than me :> You should feel better now too :>

I just gonna explain why I used the Adapter in my projects, which is also the answer of your question.

"What's the added value of not allowing the GUI to be able to persist itself?"

Think of building a project where you develop everything the DAL, BL and PL (GUI). Then you thought, why not to expose some APIs for some clients to build their own GUI on top of the other layers you've built.

Then you might want to make things easier for your APIs users, you want to abstract some information from them, you don't want them to know anything about the database structure, how to deal with connections, transactions...etc.

This can be very obvious if you have built a system that you host, then you might be hosting the database and a Web Service that others call to perform their tasks, then you won't need anyone building a piece of code that mess with everything, you should be in control of your system, and they just can call your Web Service passing some Entities to it's methods, and that's it.

You may say that you can do the same with Selfservicing and your customers will pass you some data types other than the generated entities, which might be a possibility, but this will add extra work to you, having to validate and map those parameters to your entities.

While it would be much easier if they use your Objects "Entities", and you control the rest.

BlueCell wrote:

What's the added value of not allowing the GUI to be able to persist itself?

BC

A simple reason to not allows the GUI to access the DataBase directly is the amount of concurrent connections that you DataBase server can handles. If you allows the GUI to access the DataBase directly and you have 1000 user that are requesting data concurrently, then you will need 1000 open connections (a lot of connections!). However if the GUI request the data from a remote tier (this tier can be running in the same machine with the GUI or in other machine), you can use connection pooling and get a better performance.