Jaap wrote:
So if I understand it correct, I could generate the dbgeneric code for CF that will communicatie through a webservice that uses the standard .NET generated dbgeneric and dbspecific code.
Is there an example of this setup?
There's a simple example in the docs. That's all that's to tell about this really, as a webservice is nothing more than an object with methods for the client side and a library on the service side. What you do in the client or service is up to you.
Warning note though: having a service as a tier is an anti-pattern. One shouldn't use a webservice as a tier, so exposing the adapter as a service is really not going to fly as it creates a chatty interface. You should look into message-based SOA. There are plenty of articles to find about that topic on the net.
I didn't also find any documentation or example on how I should create and deploy a .NET remoting service or webservice. All examples I found call directly the adapter or use selfservice. No n-tier example found.
Remoting doesn't work on compact framework, so it's just webservices. The thing with n-tier is that it doesn't matter much if you're using n-tier or not: at some point you're going to need to use the data access code, but in other places you're not going to need it, e.g. in the UI. So in a sense the BL tier is a service layer to the UI, the UI works with entities, but doesn't fetch/save them. It requests them from the BL tier and passes them back to the BL tier. the BL tier then uses the adapter. This is for example how HnD is setup (this forum) http://www.llblgen.com/hnd (source is for v2.0, but you get the idea)
I'm searching for an architecture where I can create one data access and business logic layers which is consumed either directly, through .NET remoting or webservices. And that I use my dbgeneric code in ASP.NET, WinForms, Windows Services and CF applications, including all my self defined properties, validation, etc..
that requires an abstraction layer for the asp.net/winforms/services/cf applications so these layers work with a BL tier/layer which hides where the data comes from. the UI layers mentioned above use the dbgeneric code, work with the entities, request them from the BL tier and send them back to the BL tier. The BL tier has classes which mimic processes for example, like customermanager, or orderingmanager, which manage a process or entity. The UI works with these classes from the BL tier for its data management and functionality on the data. these classes in the BL tier then use adapters or webservices or remote services to get the data for the requests from the UI, or send the data received from the UI to the service/database.
That way, your UI layers don't have to have code for every different infrastructure you're using.
