I am Developing a mid-size application and want to implement Application Architecture, I've read some Architecture Books and Approach and think about
AAFN (Application Arcitecture For .net) presented by Microsoft
SOA
SDLM
SDO
MVC
and vice versa ...
this is a web application that will extended with some other small application ( just think about something like a M.I.S with a (or two) core)
Whitch Projects I should have I think about
Common // to use in all projects
Framework // main framework
DAO // data access object ( entityframework or nHibernate )
UI // will available in 2 variant web and windows(wpf) interface )
BusinessEntities // all subApplication project logic will goes there
ApplicationNameProject // each application have their Own Logic (in BussinessEntities)
ApplicationUnit // each application Entity will place here
ApplicationNameProject // each application data Entity (in Application Unit)
Services // WCF Services goes here to contribute with all applications
this is the architecture witch I think about, I do not have any force to use this, I want to know whats the best fit for me, can Change all of it or add some other projects and remove these projects
any help appriciated
There is no "best small or mid-size application architecture" as a silver bullet to fit any project, so drop that idea right now or you'll be in for a world of pain down the road.
The architecture for any given project will fit the purpose of that project. In some cases, ASP.NET WebForms with a direct queries into the database will be the most appropriate architecture, in some cases MVC will be the right architecture, in some cases a windows forms application built on top of a web service that connects to a relational database through an ORM like LINQ-to-SQL or NHibernate.
You can't decide on a one-architecture-fits-all approach, it just doesn't work. Each architecture has its merits and weaknesses and thus projects for which it is well suited and projects for which it should be avoided. You should pick the approach that makes the most sense for the current project/scenario.
Given that however, I tend to take a fairly uniform approach.
If I need a quick utility project that does a very specific thing and is highly unlikely to be needed for anything else, I might use a console application with queries against my database hardcoded.
If I need a common set of queries that I'm likely to need from multiple projects, I'll write them as stored procedures to get the performance benefits and build a data access layer that will leverage these stored procedures to give me standardized business objects, in a standard DAL (data access layer)/BOL (business object layer)/BLL (business logic layer) approach. This is advantageous because it means that once I've got this set of libraries built I can float any application over the top - for instance a webforms or MVC application.
MVC is advantageous because of separation of concerns - your controller can interact with your business library simply to access the data it needs and your views are really just that - a view of the data that the user can interact with. The views do nothing more than take the current data view to the user and transport any data changes back from the user to the controller - no logic is held in the view and as such it means that it's far easier to unit test and make changes to components without affecting the rest of the application.
The drawback to a multi-tiered or multi-layered approach like this though is that it takes time to architect it properly and if you're only after a throw-away utility application like they demonstrate on stage at developer conferences then this is complete overkill and I wouldn't bother with it.
Think of it like this: Every layer, every library, every component requires justification. If there is less justification for than against, then don't do it. The key is not to do something without reason - anything you do is correct providing that you have a well thought out reason for it, and by well thought out, I mean that you've found very good reasons for and against and you've made an educated decision, you've not made a decision based on half thoughts, or worse, no thought at all.
Anything but the most trivial .NET application should have several projects: a UI layer, some kind of business logic layer, a persistence (storage) layer and accompanying test projects. Each project should interact loosely through interfaces.
In general you should create the minimum number of layers you need to make your code testable and easy to understand.
To figure out what the minimum is that you need it can be a good idea to let your tests drive the internal design of the system. Each layer should have tests in its own right, with (possibly) the exception of the top HTML layer and the bottom SQL layer.
With that in mind it helps to separate concerns as far as possible. For example SQL queries should almost never be in the same block of code as HTML support: split things into multiple layers that each do one and only one thing. This makes changes easier.
Be aware of the difference between systems architecture (where loosely coupled Web services using e.g. REST interact) and the internal design of the system. It's a good idea to decouple the Web service interfaces (as consumer or provider) in their own layers as this is an area that often changes.
These designs are an art that's best learned by practice. With good unit tests you should find refactoring an application design fairly swift, so it's a good idea to look at technologies like Spring.NET or other inversion of control containers to make this easy.
Related
I'm looking some advice on to a strategy for migrating from Asp.Net WebForms to MVC. I currently have a solution of approx 60 projects in the following format:
Solution
ProjectA.DataModel
ProjectA.Business
ProjectA.Web
ProjectB.DataModel
ProjectB.Business
ProjectB.Web
Framework.Core
Framework.Common
…etc
All data models are Entity Framework 6 using database first (.edmx) and T4 templates. Data access code is mixed between both the Business and Web (WebForms) projects. The code base has grown organically initially from a sole developer through to a small team which explains some of the bad practice in terms of SOC however we want to try take this opportunity to rectify this.
I want to start moving towards a full MVC solution and feel the first thing to do is ensure any data access logic currently residing in the Web projects is pushed to the Business layer to get Separation of Concerns. Researching into a best practice for this has taken me towards the Unit of Work and Repository patterns however further reading seems to be suggesting this is overkill.
What would be the best approach to refactoring my Business and Data Layers with the current Web Forms model in readiness for MVC. Secondly is an accepted approach for migration to MVC to bring in Views to the existing WebForms solution to create a Hybrid or to create a new MVC project, reference my existing BAL and DAL and start building the application UI from scratch?
In regards to Entity Framework, everything appears to be moving towards a CodeFirst approach. Is this something we need to be planning for if we want to go forward with a best practice approach?
We are currently a very small team and want to try make best possible re-use of our existing projects and refactor as much as possible to get into a position of beginning to move towards MVC.
Any thoughts on how I can begin to approach this is appreciated.
Thanks
Nasty app you have there. Anywas, first thing to rembmer is that MVC is a UI pattern. So in a properly designed app the swtich from WebForms to Mvc would mean just change the UI layer.
I want to start moving towards a full MVC solution and feel the first thing to do is ensure any data access logic currently residing in the Web projects is pushed to the Business layer to get Separation of Concerns
No! Data access logic should be in the DAL (hint: it's an acronym), not BL, not UI. Persistence Only. BL and UI would ask the DAL to save/retrieve their objects via Repository. And btw, EF deals with db only. Don't make the mistake to build your business objects on top of Ef Entities. One models business concept and behaviour, the other model database access. They're usually not compatible. When dealing with anything but persistence, ignore that you have a db or an ORM.
Researching into a best practice for this has taken me towards the Unit of Work and Repository patterns however further reading seems to be suggesting this is overkill.
It's overkill ONLY if you a have a very simple app that you don't care about maintaining it. I know is hard to believe but probably over 80%(more or less random number) of devs still don't understand how to properly implement the Repository pattern that's why it becomes useless for them. In a nutshell, the repo uses the EF but it's not built on top of it. The repo 'transforms' business/ui objects to EF entities and vice versa.
The repo interface should never expose IQueryable or the fact that you're using a db in the first place. So, no generic repositories and no exposing of EF entities. Also, the Bl/UI shouldn't create queries (it would mean they know how the data is stored - a DAL implementation detail), that's the repository's job. THe higher layers just tell the repository what they want, never how to do it.
Secondly is an accepted approach for migration to MVC to bring in Views to the existing WebForms solution to create a Hybrid or to create a new MVC project, reference my existing BAL and DAL and start building the application UI from scratch?
Although you can mix WebForms and Mvc in the same project, it's better not to do it (less headaches). Start the mvc app from scratch then port the web forms pages to it.
I am trying to implement modular design in an asp.net project dividing the application into different modules like HR, Inventory Management System etc. Since I am trying to keep different modules independent of each other, I separated these modules in such a way that each module is a separate Visual studio solution having UI, BLL, DAL and even a separate database schema.
Up till now I thought this as a common practice for developing Management systems and ERPs but I am searching the web for last three days but hardly found any help full stuff regarding developing modular applications. Most of what I found is mere theory explaining the concepts of cohesion and coupling but not real world scenarios. So I wonder
Is it the right approach of separating modules?
How the real world modular applications are developed?
How should the different modules communicate with each other yet they stay independent of each other.
I think there should be a core application which makes use of these modules, how should the core application communicate with these modules?
There is some data, entities , objects which are common to each module, should I put them in the core modules in order for other modules to use them (I think this will make the modules coupled to core) or should every modules maintain its own copy of data + define those object, (which I think voilates DRY)
Any thoughts, links are warmly welcome.
This is a personal opinion and is debatable.
I separated these modules in such a way that each module is a separate Visual studio solution having UI, BLL, DAL and even a separate database schema.
Sounds like a total overkill. Abstraction over abstraction makes your application pain in the neck to maintain, support, and enhance. Is it that large that you need to separate modules into separate solutions?
Is it the right approach of separating modules?
No, I think it is a total over-engineering. I would suggest using projects to separate modules. And not separate solutions. The problem with solution is that it will require external dependencies management tool, which requires a lot of effort to bring in and later maintain.
How the real world modular applications are developed?
Using abstraction (interfaces and abstract classes) and separate projects.
How should the different modules communicate with each other yet they stay independent of each other.
By using interfaces, DI, IOC, TDD
I think there should be a core application which makes use of these modules, how should the core application communicate with these modules?
Core does not communicate with modules. In fact it should ideally not depend on any other project/library. This makes it simple to reference and use in large solutions.
There is some data, entities , objects which are common to each module, should I put them in the core modules in order for other modules to use them (I think this will make the modules coupled to core) or should every modules maintain its own copy of data + define those object, (which I think voilates DRY)
I would highly recommend using a single copy from the Core project. See this questions for details of why.
This is one of those topics that is entirely subjective for the most part, but you may wish to consider a SOA (Service Oriented Architecture).
Using SOA, you can define a service (for this example, I'll stick to web services, though other service types exist depending on requirements) for each business area - an HR web service, a projects web service, a finance web service and so forth.
You can then bring all these together with a front end system that will communicate with and utilise these services, that would normally be your core application, though depending on your needs and requirements you may opt for multiple front end systems.
For the front end system I would recommend using ASP.NET MVC which has the concept of areas and will let you separate the front end into specific areas - an HR area, a projects area, a finance area and so forth that will contain the models and views for each specific area.
Doing this will let you build in a modular manner, you can build your first web service, say, the HR web service, that has methods for getting relevant HR data and so forth, and then build the HR area of your MVC application. Expanding then simply depends on building the web service, and creating the front end in the MVC application. There is nothing stopping say the HR area then accessing the finance web service if it needs finance information, but it still keeps everything in distinct independent modules.
Using this method can also be helpful in aiding future interoperability - it may be that other systems in the company will find it useful to interact with certain web services. For example, in a previous role it was useful for the companies engineering software to integrate with the projects team web service as it allowed for engineering related information to be linked to it's related project.
If the system grows in terms of resource requirements it should also be fairly scalable as it is trivial to say, offload the projects web service to another service if it starts eating a lot of system resources. It also allows you to switch modules out if need be - if you ever decided to move to say, a Linux/Java platform, you could trivially move by porting module by module with no real interruption of the overall system.
But of course, as I say, this is simply one such option and much of it depends on the specifics of your circumstances.
It is too late to answer but it seems interesting.
Since I am trying to keep different modules independent of each other, I separated these modules in such a way that each module is a separate Visual studio solution having UI, BLL, DAL and even a separate database schema.
It depends on your scale of application. If you create a very small-simple application with a little functionality, then it is safe to has a combined assembly. Or if you want, just separate the UI with other module. At least it can help you to emphasize SOC. Keep in mind that loading multiple assembly can be slower than a single assembly.
Is it the right approach of separating modules?
Module separation always has a drawback, that it is require mapping. It means slower performance in general (maybe negligible, but still there is), and slower development time. If your application will be large and complex enough, it is worth it, since you can create modular unit tests for each module.
How the real world modular applications are developed?
No exact practice though, every problem needs a solution. You won't need a heavy multi-threading or dependency injection architecture for a simple calculator application.
How should the different modules communicate with each other yet they stay independent of each other.
Using interface. You can make the implementation different later on. Example is, you currently use C# Winform for your application, communicate to the BLL using interface. Later on, you want to migrate to ASP.Net, then you just change the implementation, but keep the interface to communicate with the BLL the same.
I think there should be a core application which makes use of these modules, how should the core application communicate with these modules?
There is some data, entities , objects which are common to each module, should I put them in the core modules in order for other modules to use them (I think this will make the modules coupled to core) or should every modules maintain its own copy of data + define those object, (which I think voilates DRY)
I assume it is an enterprise level application which share the same modules / data such as employee. If it is really need to behave uniformly, then you should provide the very basic logic at the core Level. At the application / implementation level, you may has different implementation to fulfill each requirement.
Do not force to uniform all of the business logic to the core. If a specific application need a different implementation, it is hard to make the core configurable.
My company has a fairly old fat client application written in Delphi. We are very interested in replacing it with a shiny new web application. This will make maintenance a breeze and many clients want a web application.
The application is extremely rich in domain knowledge, some of which is out of our control. Our clients use the program to manage their own clients and report them to the government. So an inaccurate program is a pretty big thing. The old program has no tests. We are not sure yet if we will implement automated testing with the new one.
We first planned to basically start from scratch. But we are short handed and wanting to basically get everyone on the web as soon as possible. So instead of starting from scratch we've decided to try to make use of the legacy fat-client database.
The database is SQL Server and can be used in SQL Server 2008 easily. It is very rich in stored procedures, functions, a few triggers, and lots of tables with over 80 columns... But it is decently normalized. We want for both the web application and fat client to be capable of using the same database. This is so that if something breaks badly in the web application, our clients can still use the fat client and connect to our servers. After the web application is considered "stable", we'd deprecate the fat client.
Has anyone else done this? What tips can you give? We want to, after getting everyone on the website, to slowly change the database structure to take care of some design deficiencies. What is the best way to keep this in a data access layer so that later changes are easy?
And what about actually making the screens? Is there any way easier than just rewriting an 80 field form in ASP.Net? Are there any tools that can make this easier?
The current plan is to use ASP.Net WebForms (.Net 3.5). I'd really like to use MVC, but no one on the team knows it including me.
We are not sure yet if we will implement automated testing with the
new one.
Implement automated testing. What's the point in replacing one buggy program with another?
Good question, but "Slowly change" the db structure after getting everyone on the website, sounds like a joke...
I would rather take the opportunity to create a fresh db structure, write a bulletproof migration script for you db, that you can try out and rewrite a zillion times without any side effect fro your clients, and then write whaterver you want (fat/web) on the new db, have it tested and migrate everyone when it's ready.
I have a couple suggestions:
1) create a service layer to abstract away the dependance on the DAL. In a situation as you describe having a layer of indirection for the UI and BLL to rely on makes DB changes much safer.
2) Create automated tests (both unit and integration), especially if you plan on making fairly significant changes to the Domain or Persistance layers (BLL/DAL). To make this really easy you should always try to program to an interface. This makes your code more flexible as well as letting you use mocking frameworks (Moq is one I like) to ensure your tests truely are unit tests and not integration tests.
3) Take a look at DDD (http://domaindrivendesign.org/) as it seems to fit pretty well with the given scenario. At the very least there are some very useful patterns that can help make your application more flexible.
4) MVC isnt very hard to learn at all, it is however an easy way to get unit testing setup for the UI as a result of the MVC architecture (testing the controller and not the view). That said, there is no reason you couldn't unit test web forms, its just a bit more work. MVC really is just a UI framework/design pattern (more Model2 but we can ignore that for now). It gets you closer to the metal so to speak as you will be writting a lot more HTML and using a Model (the 'M') for passing data around.
For DDD take a look at Eric Evans book: http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_1?s=books&ie=UTF8&qid=1317333430&sr=1-1
Hope that helps
ASP.NEt forms is a no starter, is completely inappropriate for something like this. I recommend to start with something like Creating an OData API for StackOverflow including XML and JSON in 30 minutes, then build your Web app on top of that (ie. push it to the client, use JQuery/Silverlight).
i.e. Is MVP still the next best choice when MVC is not an option?
I thought I'd ask this here as I'm sure there are others like me who don't have the luxury of being on a green-field project and want to refactor a webforms UI to better separation of presentation from business objects...
I'm working on a legacy application tasked with adding relatively small additional requirements, enhancements, and bug fixes.
The part of the application I'm addressing here may be characterised as the UI for a set of CRUD operations over business objects that are persisted to a relational database.
The existing UI uses a MultiView control to navigate between the editing of associated business objects (one-one associations or one-many / parent-child). Yes, that's right - all on one page. Unfortunately there is very sparing use of UserControls so the markup and code-behind is hundreds of lines long.
On each View a FormView manages the CRUD over the business objects via various ObjectDataSources. Within the ItemTemplate of each FormView various server controls databind to fields or methods on an ObjectDataSource.
I'd like to introduce more separation of concerns and get some of the reams of code out of Page code-behind.
My research so far suggests to me that I might consider:
Use a flavour of Model View Presenter; more specifically - use an ObjectContainerDataSource from the Web Client Software Factory to make it easier to bridge between the current UI and a set of new Presenter classes.
Build again from scratch with an MVC framework (not an option).
Leave well alone; an MVP pattern is only justified if I need to re-use my Presentation in different UI scenarios?
If I settle with (3) I'd still like to know how to start refactoring towards better separation of presentation.
What would you do? any other ideas gratefully received...
Here's some more background for anyone who's interested:
The domain is in pharmaceutical research but that's fairly irrelevant and you can think of it as pretty typical line-of-business - user configuration of a family of settings that form the operating conditions of another part of the application.
The business object layer has already been built in a very consistent manner. Although I may not like it, I can't neccesarily justify changing it. Each object is it's own Repository / Data Access Object in that there are static methods for 'get by ID' and 'get list by criterion'. Where possible common operations are implemented in an abstract base class. Each business object delegates the data access work to a Data Access Layer that makes use of ADO.NET 2.0 Provider Factory mechanisms to remain relatively abstracted from a concrete Provider. In this respect it shares a lot in common with any app that uses the Data Access Application Block from the Microsoft Enterprise Library.
There are fairly exhaustive integration tests written in NUnit that set up a test database from scratch so they take ages to run but at least they verify that stuff works as it should (at some point in the past anyway ;-). There is almost no true unit testing in place (yet).
WebForms now has an emerging effort in the form of the ASP.NET Web Forms MVP project
"...there are still a host of
compelling advantages to ASP.NET Web
Forms.
The ASP.NET Web Forms MVP project is
... an approach that facilitates
separation of concerns and testability
whilst maintaining the rapid
development that Web Forms was built
to deliver"
Rob Conery has concerns that this may be a wasted effort and an unneccesary distraction now that we have MVC but at this stage I still think the source code is worth a look...
http://haacked.com/archive/2006/08/09/ASP.NETSupervisingControllerModelViewPresenterFromSchematicToUnitTestsToCode.aspx has a good example of doing MVP with webforms. The advantage is not just that your UI is decoupled from BL - the real treat is that you can write tests for the code.
Is it "acceptable" to have an ASP.Net 2.0 application without the BLL (Business Logic Layer) as the following?
SQL Server Data Storage & Stored Procedures
Data Link Layer (Strongly Typed Table Adapters) connecting to Stored Procs
Presentation Layer ASPX Pages with Code behind and ObjectDataSource for connection straight to the DLL
Is a BLL always preferable, even if business logic is entirely validatable in the presentation's code behind? What are the potential drawbacks for not using a BLL?
It's acceptable as long as you understand the consequences. The main reason you'd have a BLL is to re-use that logic elsewhere throughout your application.
If you have all that validation logic in the presentation code, you're really making it difficult to re-use elsewhere within your application.
Like everything else it is environmental and depends on the use of the system. The question you need to ask your self is:
Will this be actively developed
Is this going to be used over the course of many years and expanded on
Is the expansion of the application unknown and thus infinite
Really it comes down to laziness. How much time to do you want to spend reworking the system from the UI? Because having no business layer means duplication of rules in your UI across possibility many many pages.
Then again if this is a proof of concept or short demo or class project. Take the easy way out.
Acceptable? Depends who you ask and what your requirements are. Is this app an internal one-off used by you and a few other people? Maybe this is good enough. If it's meant to be a production ready enterprise application that will grow and be maintained over the years, then you probably want to invest more effort up-front to build a maintainable app.
Separation of Concerns is a key design technique for building maintainable apps. By mixing presentation, business, and data access logic all together, you can end up with a very fragile difficult to change application architecture.
It depends. If your business logic is in your click events and page loads, it is NOT acceptable.
It appears that your business logic is somewhere within the DAL (e.g., stored procedures and such), just as long as you are consistent, it's fine. As long as you are very, very sure that your clients will always be using SQL Server then this approach is not a problem.
I know a colleague who has all his business logic in stored procedures that his views are mostly thin clients to database backends: he has been immensely successful with the product that he sells. But that's only because he's very consistent with it.
If the application is a general one, then the business logic layer can be used in complete other applications too. Like, I normally use my CMS related BLL classes in other applications.