I'm in the situation that I have to design and implement a system from the scratch. I have some questions about the architecture that I would like your comments and thoughts on.
Quick Info about the project: It's a data centric web application.
The application will be built on Microsoft .NET Framework 4.0 with MS SQL SERVER 2008 database.
Requirement:
Rich UI and robust
Multi-device support (every browser and on every device)
Loosely coupled
Below is the architectural diagram I have built:
Briefing of the architecture
Presentation layer : HTML5/ASP.NET MVC + JQuery (Web application for multi-device support in first version)
Distributed Services : WCF (XML/JSON/JSONP)
Domain Layer(Business Layer) : All business logic
Data persistence (DAL Layer) : Entity Framework 4.0 with database first approach. POCO entities are generated and separated out using T4 template
Infrastructural Layer: Contains common libraries like POCO entities, Exception Handling, logging etc
My Concerns :
As application is to be built loosely coupled so in future if business requirement grows new modules can be easily plugged in without affecting the architecture.
So I thought of using the Repository pattern along with IoC and DI (can be Unity/Ninject/Sprint.NET or any other)
WCF with both XML and JSON support
Distributed Service Layer to place IoC & DI
Exception Handling & Logging using Enterprise Library 5.0
Looking for valuable comments and suggestions.
If I am doing anything wrong please put me in right direction.
I would suggest the following comment: right from the outset your approach will create tight coupling. This goes directly against your requirement #3 "Loosely coupled"
In your diagram you have defined two modules. Main module, and Module 2. I would guess that these two modules are quite distinct from each other. What I mean by this is that you could develop them completely separately and then plug them in, because the business concerns they address are different.
However, your current architectural approach:
Couples Main Module and Module 2 data into the same database
Couples Main Module and Module 2 business objects into the same business layer
Couples Main Module and Module 2 services into the same service layer
Couples the deployment and management of Main Module and Module 2
What may be worth considering: Build Main Module and Module 2 as separate vertical service stacks.
What I mean is Main Module and Module 2 become Main Service and Service 2
Each service has it's own database, it's own business layer, it's own services layer and it's own UI components.
However, this raises the concern: how can Main Service and Service 2 both work together to create my product?
To address this:
At the UI end, you stitch your front end together by using client-side code to load responses from the Main Service and Service 2 into one view.
At the back end you use publish subscribe messaging to allow Main Service to subscribe to events happening in Service 2 and vice versa.
This will result in an application built from the ground up on top of loosely coupled vertical service stacks, which maintain consistency by the asynchronous exchange of messages.
If you then need to add in a new module to your application, you can create a new service stack which supports the desired capability and wire it up with little or even no change needed to the other stacks (ideally the only reason to change existing stacks would be that they want to subscribe to events from the new module).
It's a very different approach to the one you're suggesting, but one which allows you to meet the requirement for loose coupling better, in my opninion.
How come that the architecture diagram doesn't use the domain layer for ASP.NET?
It seems to me that you may be overarchitecturing your application. Also, while it looks great to support 6 (or so) different front-end technologies, the effort to maintain all of them will be horrendous. I'd stick to one technology for the front-end - most likely HTML5 with client-side MVC or similar.
It makes sense that the WPF, WinForm etc UIs should call the WCF layer. I'm assuming that it's a business requirement to have multiple UIs, otherwise if you can only have one UI a responsive web UI is the most flexible choice.
However, I don't think your MVC UI needs to use the WCF layer. It could call the domain layer directly. That would be faster and remove a pointless layer.
Obviously, that would only work so long as you don't put any logic in your WCF layer. And the WCF layer really shouldn't have any logic in it.
You also state that you want to place IoC & DI in the Distributed Service Layer. That doesn't make much sense in terms of your MVC UI. You'll need to use DI in the MVC project so you can unit test the controllers.
Looking at your diagram I have a couple of points I'm not clear on:
Where is the domain model? Domain Core or the 'model' in the persistence layer?
How does the domain layer interact with the data access layer? The interaction is not as clear as between the service/application layer and domain layer.
What the difference between a repository in the domain layer and a repository in the data access layer? I usually make the distinction of having 'model repositories' in the domain layer which act upon domain model objects, and 'data gateways' in the data access layer which act upon DTO's.
What is domain core? Is this the implementation of the application layer transactions?
Does there need to be a further abstraction of the persistence framework? (EF)
Related
From The Official Guide - Mastering ABP Framework, Chapter 15 Working with Modularity, page 416, there are 4 isolation levels for an applicaion module defined in the book, one of them called 'Bounded contexts' and it's definition is as below:
A module can be part of a large monolith application, but it hides its
internal domain objects and database tables from other modules. Other
modules can only use its integration services and subscribe to the
events published by that module. They can't use the database tables of
the module in SQL queries. The module may even use a different kind of
DBMS for its specific requirements. That is the bounded context
pattern in domain driven design. Such a module is a good candidate to
convert to a microservice if you want to convert your monolith
application to a microservice solution in the future.
My question is:
An ABP application module solution is formed by several projects, for example:
Application
Application.Contracts
Domain Domain.Share
EntityFrameworkCore
HttpApi
HttpApi.Host
Web
As we known, each of those project will be compiled to an individual assembly, so how can i achieve 'The module should hides its internal domain objects and database tables from other modules'?
For a microservice, a bounded context is isolated in the application level, so it still can use the 'public' modifier to declare the aggregate root or other entities and then the application layer can use them. But a bounded context as a application module will be referenced by other modules or applications, once been referenced, all the public members can be directly use, how can I make them 'invisible' to other modules but at the same time 'visible' to the application layer inside??
One way i think of is to use the ‘internal’ modifier to declare all the entities, Aggreget roots and all other domian objects, but in that case, the Application layer will not be able to use the objects from the domain layer as well. so to overcome that, i need to combined the application layer and domain layer into a single project, but doing this really makes me feel very inelegant, and the most harmful side-effect is that the entities inside the aggregate will exposed to the application layer.
I can't find any example from the official guid and the website docs, is there any 'best practice' around?
I'm about to create a new imposing web project using Play! framework (similar to Rails philosophy).
After reading some important parts of this famous book: Service-Oriented Design with Ruby and Rails for learning some tips on good design, I wish to avoid monolithic application by creating separated Play! applications as services layers (through REST).
Thus, I imagine the first Play! application would be responsible for routing clients' requests to remote services layers contained each one in other Play! applications.
I wonder both things with this solution:
Where to put Entities/Values Objects (data model)? May there be some kind of data-model.jar shared between view application and services applications? (Optional for view since DTO's or JSON object would be sufficient)
View application would end up with no model layer, since view application acts as a simple proxy for services applications. Doesn't it promote confusion or potential bad understanding for future developers (an application with view/controller but without model part)? Likewise, services applications wouldn't contain view layer...
In short, each of these applications using Play! would seem to follow this bad principle: YAGNI
I’m working on an application which has been designed using n-tire application architecture .The application was developed in the .NET platform utilizing C#,VB.NEt, Framework 3.5, Dataset, WCF, asp.net update panel, JavaScript ,Josn, 3rd Party tools.
my current proposed layout is such
presentation layer -> Business Logic -> WCF -> DAL->Data access
The point Is:
Is the above layout the right way to build SOA systems ?
As always, your advice is greatly appreciated
This depends on your definition, see Fowler's comments.
Generally, in order to get the most benefit from something SOA, you're services should be designed to be reusable by multiple consumers. This means placing your business logic "beneath" your WCF layer. Then you can have, for instance, a Silverlight client, a WPF client, etc. using the same services and business logic.
Change your scenario to:
Multiple Presentation Layers -> WCF -> Business Logic -> DAL-> Data access
Looks like it COULD be correct although I'd put WCF between your Pres and Biz layers too. Also, don't be afraid of having a non-linear path for your SOA architecture (i.e. having side services like an "EmailService" and "WeatherDataService" that come from the side of your N-Tier path. Obviously the WeatherDataService would come from the side of your DAL but the EmailService might come from the side of your Biz layer.
Some great links for you:
Doing N-Tiers with WCF
WCF and Datasets with N-Tiers
N-Tier with WCF, MVC, and LINQ
Your services should be business operations, not data operations. A better version of your design would be:
presentation layer -> WCF -> Business Logic -> Data access.
N-tier / layering is a pretty dated concept these days. It always broke down. Instaed, think of your software as a number if interacting services.
Using VB.NET 2008
I want to know what is 3 Tier Architecture for windows application?
Can any one give a example of How to make a code for Inserting, Deleting, Updating in a database using 3 tier architecture.
Note am not asking a real code. Just give me a example.
From Multitier architecture
Three-tier'[2] is a client-server
architecture in which the user
interface, functional process logic
("business rules"), computer data
storage and data access are developed
and maintained as independent modules,
most often on separate platforms.
These days, a normal 3 tier application consists of a user interface written in Javascript, CSS and HTML which runs in the browser, a business rules layer which runs in a web server, and could indeed be built in VB.NET, and a storage layer which runs on a database server written in SQL and stored procedures.
Now it would be possible to do a user interface layer in VB.NET as a Windows application which then calls the business rules layer on the web server using a web services interface. This would give you more flexibility than the browser, and would not require learning as many APIs, however it is not common. It can really only be done in an enterprise situation.
This article has a simple VB.NET application that is a Windows GUI app, which call Google's web services API to do searches and to check spelling. That is a good example of a user interface layer. Then check this article for and exmple of a web service developed in VB.NET. This corresponds to the business rules layer, and in a real 3-tier application, it would be based around a database such as SQL server. If you were to use Access then it would not be a real 3-tier application. The database needs to be run on its own server and accessed across the network in order to be considered a tier.
The advantage of a 3-tier application is that you can scale each layer separately, and because each layer is simpler, scaling is also simpler. The DBAs can scale up to a database cluster, the business rules layer can scale up with a load-balancer and multiple servers, and the user-interface just gets replicated across as many clients as you need.
I don't know if is it the right way to use it, but I often use 3-tier int the following way:
One big Solution, with the name of the project
One dll project wich has the conection with the DB, using LINQ or whathever. Validating only the required fields of the DB
Another DLL project, wich has a reference to the project that conects to DB, and validate all data using the bussiness rules. Sometimes you may want a repositorium class wich has methods that can be used from the GUI layer
Finally, the GUI layer that can be HTML or WINForms, wich references to the bussines layer and calls all the appropiates methods, passing the data transparently and waiting for validation on the bussines rules.
You can comunicate with each layer using bool methods that returns true if everything is good, and personalized exceptions for each of the possible errors, and catch them on the upper layer.
I'll give you the gist of it. Real crash course.
You have three tiers:
DAL - Data Access Layer
BRL - Business Rule Layer
Presentation - The Forms, and such.
In the DAL, you configure how your application connects to databases, how it recieves datasets, etc. etc. Everything that has to do with data access.
In the BRL, you lay down how your program is going to handle the data it recieves from the DAL. Methods, and other things go in here.
And in the Presentation area, you simply make things purty and instantiate things from the BRL. The presentation area never has to touch the DAL, and that's the beauty of the 3tier layout. You can work on different areas and not step on other peoples toes.
I find the best way to understand it is to look at an example. If you go here:
http://www.codeproject.com/KB/vb/N-Tier_Application_VB.aspx
You can download an example and read the walk through for creating a very basic 3 Tier App in VB.Net. It's a little old in that it's a Visual Studio 2003 project but it should be easy enough to follow the upgrade wizard and get it up and running to check it out.
I'd like to give a brief overview about this style of programming and maybe I'll explain it in more details next time.
First of all, the 3-Tire concept engages dividing your program or application you are designing into 3 layers, the first layer is for manipulating the database in the operation called CRUD which stands for {Create,Read,Update,Delete} data from your database, using any kind of Databases : for example Oracle,SQLserver,MySql etc. That means you can connect your application with any type of databases without specifying a connection String to Only one database and we'll get more details about this next time.
The Second layer is Business layer which includes user data verification and other similar operations in which you process your business rules and the core of program,
The Third and Last layer is the Presentation layer which relates to User input and UI User Interfaces {The different forms for Input}
Frankly you can divide your Solution {Program,Application,Website} to sub-Programs to avoid data loss,organize your work, and to divide the development of your application among a team members.
in my point of view this is a great thing should be learnt in development, and as I was told by the grapeVine, if you want to enrich your knowledge and experience then you should be acknowledged about this important subject.
In my SOA architecture, I have several WCF services.
All of my services need to access the database.
Should I create a specialized WCF service in charge of all the database access ?
Or is it ok if each of my services have their own database access ?
In one version, I have just one Entity layer instanced in one service, and all the other services depend on this service.
In the other one the Entity layer is duplicated in each of my services.
The main drawback of the first version is the coupling induced.
The drawback of the other version is the layer duplication, and maybe SOA bad practice ?
So, what do so think good people of Stack Overflow ?
Just my personal opinion, if you create a service for all database access then multiple services depend on ONE service which sort of defeats the point of SOA (i.e. Services are autonomous), as you have articulated. When you talk of layer duplication, if each service has its own data to deal with, is it really duplication. I realize that you probably have the same means of interacting with your relational databases or back from the OOA days you had a common class library that encapsulated data access for you. This is one of those things I struggle with myself, but I see no problem in each service having its own data layer. In fact, in Michele Bustamante's book (Chapter 1 - Page 8) - she actually depicts this and adds "Services encapsulate business components and data access". If you notice each service has a separate DALC layer. This is a good question.
It sounds as if you have several services but a single database.
If this is correct you do not really have a pure SOA architecture since the services are not independant. (There is nothing wrong with not having a pure SOA architecture, it can often be the correct choice)
Adding an extra WCF layer would just complicate and slow down your solution.
I would recommend that you create a single data access dll which contains all data access and is referenced by each WCF service. That way you do not have any duplication of code. Since you have a single database, any change in the database/datalayer would require a redeployment of all services in any case.
Why not just use a dependency injection framework, and, if they are currently using the same database, then just allow them to share the same code, and if these were in the same project then they would all use the same dll.
That way, later, if you need to put in some code that you don't want the others to share, you can make changes and just create a new DAO layer.
If there is a certain singleton that all will use, then you can just inject that in when you inject in the dao layer.
But, this will require that they use the same DI framework controller.
The real win that SOA brings is that it reduces the number of linkages between applications.
In the past I've worked with organizations who have done it a many different ways. Some data layers are integrated, and some are abstracted.
The way I've seen it most successfully done is when you create generic data-layer services for each app/database and you create the higher level services based on your newly created data layer.