Software Engineering, Project Management, and Effectiveness
We created a Web Application with Domain Entity Application Pattern as part of our patterns & practices Application Architecture Guide 2.0 project. The purpose is to show a baseline architecture based on patterns.
Scenario Here's the backdrop we use for the baseline architecture:
Pattern Solution Here's our pattern overlay:
Tech Solution Here's our technology overlay:
Application Pattern You can review the full application pattern on CodePlex at:
We created an initial set of Application Patterns as part of our patterns & practices Application
Thanks for posting these pattern baselines. They are very helpful for understanding, in brief, the patterns in the App Architecture Guidance.
1) the technology solution overlay for its description of the suggested technologies for each layer and pattern,
2) the use of domain entities and data mapper, and
3) the intended location of each layer.
I would make the following improvements:
1) "Domain Entity" makes me think of "Domain Driven Design" (DDD), but the inclusion of the Transaction Script pattern indicates this is not correct. Further, the Domain Entity and Repository pattern objects would normally fit into the BLL in DDD but instead are found in the DAL.
2) I am not sure what a "Facade Interface" means from the diagram. My thought is that you have an interface (the facade) and an implementation (the business process object).
3) Use of Entity Framework (and other O/R mappers with a Unit of Work pattern implementation, which is also missing from the patterns) requires careful management. To what level should the Unit of Work--in this case the ObjectContext--extend? My assumption is that each layer talks directly to the underlying layer and no further.
Thanks again for these pattern diagrams and the opportunity to offer feedback.
This pattern does nto handle the sceanrio where we would liek to have 3 physical tiers for security peurposes. Wwb Tier, Application Server Tier and data tier with Web tier sitting in DMZ and Application and Data tier in secure zones.
What set of patterns should be utilized for that scenario.
Good points and thank you for your feedback.
You can roughly model from this pattern - http://www.guidanceshare.com/wiki/ASP.NET_1.1_-_Web_Services_to_SQL_Server ... while the technologies have changed, the core concepts are still there.
You can also browse here to get some further ideas:
This pattern seems suited for my purposes where everything -database included- is to be created from scratch. Except the end users will be in other offices around the country.
Is the pattern still applicable if the server can be isolated from the rest of the company's network and only used for this application?
Furthermore, is there a reason why in this case the web and database servers should not be on the same machine?
You can use it as a baseline, but you'll want to spike on your high-risk scenarios.
Normally the database is factored from the Web server because of security reasons or an existing infrastructure. For example, you have an existing database, but then you add a Web client that talks to the database.
Thank you. I'm not an expert and though I understand the various scenarios, I guess I'm trying to figure out which way makes more sense.
For a small company with budget constraints, for an application that is self-contained, to be accessed exclusively over the Internet and needs no other network resources, I'd be interested to know what the balanced (risk/budget - and budget means both hardware and all software needed, plus the complexity of the app itself) option you think would be:
a. a hardware/software solution integrated in the main network - and that means a four-tier system is needed to protect the rest of the network
b. a two or three-tier system on a separate little network and I don't know what's involved in having another internet connection set-up
c. (and I might be completely off here) only the software componment needed - i.e. could the app be hosted by a website hosting provider?
I would explore hosting options. If you don't have existing infrastructure and operations in place, I would compare hosting options that take care of reliability, performance and security. Also compare which development environments they support. Then you have a baseline to compare against your homegrown solution.