I am quite new to the architecture and I am desiging an application for my next .NET project. My proposed architecture design is as follows:
It is traditional three tier application which contains: DataLayer (LINQ + Partial Classes) BusinessLogicLayer (Entities + Validation Logic) (Optional) Service Layer (WCF) UI (Web site and Windows App)
Data Layer: The data layer will contains my DataContext classes (i.e. LINQ) and partial classes. These partial classes will have basic calculation logic (for e.g. Calc. VAT) and other database level validation logic.
Business Layer: This will have entiries similar to Data Layer but also will contain validation logic at UI level. For e.g. if user try to enter username which does not exists in the database it needs to tell user that user does not exists. (this is the place where I am struggling). The object will be Lazy Loaded whenever the properties will be called and not when the Object is created.
UI: This will be a traditional UI layer where Business entities will be invoked.
The reason why I am saperating the business layer from the DataLayer even when using LINQ is becouse if I wish to add more middle tier entities for e.g. WCF service then I want it to talk to Business Layer rather then Data. I belive decoupling helps when the application grows.(I think)
I would appriciate if someone can comment on above lines. My real problem is writing the business classes (obeviously). For e.g. In Lazy loading when I try to Load the Object and it there is no data in the database then I want my UI to show the user that the user does not exists (if I am searching for username). What are your recommondations with regards to this. Any input to this is much appriciated.
Many thanks, Preyash
One piece of advice here is to follow the KISS/YAGNI paradigms. Don't necessarily dive in with a complex architecture just because you think you'll need it later when your application grows.
Maybe start with looking at exactly what your application needs to do, and think of the simplest way in which this can be achieved. You will save your self loads of time and get a prototype up and running very quickly which will almost certainly teach you a lot about the problem that you can then factor in to the next version or enhancement.
With regards you question on the user interface, this is a good example of where keeping the architecture simple keeps everything else simple. A simple method to load a user that returns null if the user doesn't exist can easily be interpreted by your UI. But once you get into complex business objects you need to think through a lot more implications. Your UI becomes tightly coupled to the complex business objects rather than a simple data access CRUD interface, so you might say your application has become more coupled rather than less.
My approach when creating applications for clients is generally to have as thin a server layer as possible. Keeping the business logic with the data (i.e. in the database) and the UI logic in the UI (i.e. in the client), all the server does is pass very simple data objects between client/server using web services.
An alternative, if you're not a fan of logic in the database, would be to put the logic in services.
In both cases I think there is merit over putting the logic into new business entities, because if you do this you are passing your logic around the application and so increasing coupling, rather than passing the data and keeping the logic private.