Hi All,

Ok, I have read a hell of a lot in the forums and I want to thank everybody for some really, really good threads. My knowledge of LLBLGenPro as well my own understanding of different architecture solutions has increased dramatically thanks to you.

Frans, the 'Just Enough Structured Analysis' reading was, well, fantastic and I did learn a hell of a lot (http://www.yourdon.com/books/msa2e/) if anybody else is interested.

It has now come to the point where I need to start working on my new project but before I do I just wanted to ask the panel as so to speak on how they would go about architecting a design like mine. You see I have a good idea of what I think it should look like but there is no harm in asking others on how they think would go about it. Some of the technologies that I was to implement I have not done before so as 'BT' say (British Telecom Company'), 'it's good to talk'

Scenario:

1. My UI will be winform based.
2. Simplistic security, i.e. username and password.
3. The application must allow connection to a db locally, network or internet.
4. LLBLGenPro is a must for the DAL.

What I would really like comments on is 3. If connection is to a local db then this could be classed as my single user application, network is multi user and internet is to allow remote users to work from home who connect into the network db.

What about the tiers? Should there be a BLL that determines how to connect to the db? Selfservicing, Adapter? hmmm, Any comments would be really appreciated.

Geoff.

Question1 is the db platform the same for the local and remote system, i.e. are the local users running MSDE and the main servers running SQL Server? Or do you need local users to run MS Access then ship the data to SQL Server at a later point in time? Do the users pick the db that they access or do they fail over into local mode if they cannot connect to the central server?

Question2, are internet users really using the internet? i.e. http protocol on port 80 or are they using VPN over an internet connection? If VPN isnt an option for "remote" users is it possible to open non-standard TCP IP ports?

IMO these are big questions.

As far as the LLBLGen pattern to use, if your requirements are really as you have described them, youll probably want to use the Adapter pattern because it is more abstract and will allow you to position service layer facades in front of the entities as well as allow you to abstract the data access adapter to make the underlying RDBMS more transparent.

Hi Devildog, thanks for replying.

Devildog74 wrote:

Question1 is the db platform the same for the local and remote system, i.e. are the local users running MSDE and the main servers running SQL Server? Or do you need local users to run MS Access then ship the data to SQL Server at a later point in time? Do the users pick the db that they access or do they fail over into local mode if they cannot connect to the central server?

Sorry, I probably might of not made myself clear enough. User's will be able to pick their own connectionstring as so to speak but the underlying db will always be the same.

What I am thinking here is that the UI should be allowed to connect to any local/network shared file based db, maybe this has to be MS Access? I did want to use VistaDB.NET but I will have to wait for Frans to implement it, hopefully.

The UI should also be allowed to connect to any remote db whether through remoting or web services if it's possible but the underlying db would probably be the same as local unless there is a good reason not to use the same.

Funny you mention fail over and it is relevant for the future because I want to UI to be able to go offline/online with a remotely connected db but not at this stage. Either the UI is connected to a local db or it is connected to a remote db.

Question2, are internet users really using the internet? i.e. http protocol on port 80 or are they using VPN over an internet connection? If VPN isnt an option for "remote" users is it possible to open non-standard TCP IP ports?

Good question, I didn't think about this well enough. I am not sure about VPN but lets say its not available. It is definately possible to open non-standard TCP IP ports and I am in total control of the infrastructure needed to allow the UI in question 1 to be able to connect to a db that is remote.

IMO these are big questions.

They are and i'm grateful for the advice. The project could be quite large so I wanted to throw a couple of thoughts around on the best way to achieve my goal especially for the local/remote connecting of a db and where that would be achieved in a design.

As far as the LLBLGen pattern to use, if your requirements are really as you have described them, youll probably want to use the Adapter pattern because it is more abstract and will allow you to position service layer facades in front of the entities as well as allow you to abstract the data access adapter to make the underlying RDBMS more transparent.

Thanks, good tip.

With respect to your solution the approach that I would probably take would be to create an LLBLGen project then code gen the entities. From there, I would use the template studio to create manager classes for all the entities. Then I would create domain classes, which are simply classes that group functionality from the manager classes. My domin classes would be my services layer.

Once the services layer is in place, you should have all the hooks needed to connect directly to the services layer, or via remoting, or to create a web services wrapper.

Another question you might find yourself asking is should LLBLGen entities be passed across tiers, i.e. should the client know about a CustomerEntitiy etc. Some people dont do this and some do. I do (unless I am using web services). So as far as deployment is concerned, you would need to deploy te runtime libraries for lblgen, your assemblies for your entities, and either your services layer assembly OR if you use a shared interface approach with your services layer, simply deploy the assembly which contains the interfaces.

DevilDog,

Many thanks for your suggestions. Appreciated.

Geoff.