I am currently building guidelines and standards for my team. We build two types of applications:
Business Web Applications using Java + MVC2 (EJB3, Struts and JSP) for transactions, scalability and persistence.
Light Web Applications using Java + Struts and JSP for small applications like surveys, small forms, etc. Basically, it's like MVC2 without the model part of it.
I am looking for the right pattern or practice name for the Light Web Applications. I guess "View-Controller" could do the trick but I am trying to find a diagram that would illustrator that "pattern" properly.
Any idea?
Related
I'm architecting a new App and I really unconfortable with this approach in ASP.NET Core that made "normal" adding a DbContext by using AddDbContext, in services.
I'd like to know if you guys think that using AddDbContext in ASP.NET Core isn't a bad practice, since it forces my Web App to have a dependecy on my database access layer.
I've researched a lot and it was incredible that there isn't almost anything that cover this subject.
How should I proceed to overcome this concern?
Thanks!
it forces my Web App to have a dependency on my database access layer
That's exactly the place where it should be: the composition root. Your application startup code is the place where you glue your components together.
What else would you want, create a separate library, containing interfaces for all classes in your entire DAL, and wire that up using magic during startup?
I want to start to develop my own social networking site in asp.net mvc with Entity framework code frist methodology (linq,back end ms sql server)...is it best choice to select this platform and why?
so, i will start to develop and also any info or link is there please send me??
No technology really does provide anything out-of-the-box. You can use MVC with entity framework but also ASP.NET with Linq to SQL (just as an example)
Either way you will have to build it from scratch if you do not want to use external controls. I would strictly recommend telerik (www.telerik.com) They offer great controls for mvc as well as for asp.net. But even if you use external controls you have to design the data/object-structure by yourself
There is no one true platform that is geared towards writing a social networking web application. Most have their advantages and disadvantages. If you are a .NET developer and you need to build something in RAD then use web forms, if you want to build something with separation and clean code in mind, use MVC.
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 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)
I am exploring WCSF and wondering how is the data access layer created? Some of the articles I have found are two years old and talk about using Web Service Factory. I am using VS 2010 and .Net 4.0. I am looking for some sample and tutorials with real world examples.
The Web Client Software Factory doesn't provide automated guidance for creating the data access layer. It's focus is primarily on providing guidance to facilitate composite Web application development (i.e. Web applications which are comprised of individual modules, often developed by different development teams).
There are several approaches for accomplishing data access, but a few resources you might want to check out are the ASP.Net MVC Nerd Dinner tutorial, the S#arp Architecture project, the Code Camp Server source, and the Microsoft Pattern & Practices Data Access Guidance. All of these use variations of the Repository pattern which is the predominate approach among teams following Domain-Driven Design.
There is a good reference implementation hidden in the WCSF2010 Source file, and a few other examples. On http://webclientguidance.codeplex.com, click Web Client Software Factory 2010 Source and then download WCSF2010Source.zip. Inside you'll find Trunk\Source\GlobalBankRI\GlobalBank.Commercial.EBanking (VSTS Tests).sln, which is a pretty good example of many aspects of WCSF, including data access through a WCF service. There are some other simpler examples in the Trunk\Source folder.
Only the ETF module is fully built out. Each view presenter uses an ETFController to manage data common to all presenters. The ETFController uses an instance of IAccountServiceAgent, realized by AccountServiceAgent (for non-unit testing), which is registered as a module. AccountServiceAgent uses a class that acts as a proxy for the WCF reference. The proxy instance to use, AccountServiceProxy, is hardcoded.
The actual source code for WCSF is in BlocksTrunk\Source.
Yeah, not at all easy to find. I don't remember what made me download this and look inside for such examples. Certainly not anything I read on the website.
I've used this example to build a web app that access SQL data and scrapes a website, if you'd like to take a look. It's still under development, but the data access bits are pretty firm: http://lcbodrinkfinder.codeplex.com/