We are going to develop content Management System in ASP.net.Please suggest us what is the good design pattern do we need to follow in order to have good design.
What design are you looking for?
User interface? Even that question depends on who your user audience is going to be. You design a system for tech-savvy users differently than one designed so that "grandma" can use it.
Business Objects?
Database table and stored procedure design?
Coding standards?
This is way too vague for an answer that could be of any practical help.
I belief it's not the right start to search for usefull patterns first.
Take a look at Graig Larmans Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development
It's all about the design. First write down the requirements. What do you want to develop. What should the features be. The Applying UML book is very clear about this. I can't explain it in a few sentences.
Related
The DevExpress XAF does much basis work for you, it creates a database based on your business objects, and dynamically generates a UI based on these, with basic functions like add, delete, sort etc. already present.
This leaves me wondering how to go about properly designing and modelling an application built on this framework. I could only model my business objects, or I could identify functions provided by the framework and include them in a details model down to sequence diagram level, but so much is being done by 'external' calls that I feel I would be wasting valuable time.
I am hoping someone with experience modelling application designs for this specific framework can give me some advice on what areas I should focus on.
As for DC, as Leon mentioned above, it has many benefits compared to the regular persistent classes. If all goes according to plan, we will release the Domain Components technology in the near future, and resolve all the remaining issues with it.
If you feel that it is hard to learn, please let us know the most difficult parts you experienced. We will be glad to review them and possibly make the things easier for you and other users.
P.S.
I apologize for the delay in responding; I was on sick leave. You will receive more timely responses if you post your questions in the DevExpress Support Center.
#ProfK:
Am I correct that you are looking for something like visual designer for your business models?
If so, then I am afraid that XPO (XAF) does not currently provide such a functionality. However, you can use free third-party tools for modeling, such as Liekhus ADO.NET Entity Data Model XAF Extensions
I hope you find this information helpful.
I'm using XAF for almost two years now and I'm very happy with it. Developing an app is very quick, nice architecture, both Win and Web the same time and great UI. As with all frameworks, it has a learning curve, but if your already familiar with DevExpress controls that it's not very hard.
As Dennis mentioned, most behaviour can be overriden or extended. Regarding your modelling question, if think an important choice you have to make is whether or not you will use their Domain Components technology. Basically they have 2 ways: the old fashion way by inheriting from the XAF or XPO base classes or by using DC. DC allows a clean separation in modules and allows multiple inheritance. They can do that by generating classes runtime, but it still has some issues.
And the framework comes with a Business Class Library, a set of common classes which may be useful.
When I get stuck or cannot find the answer myself, I always use their fantastic Support Center. Most issues I ran into were already asked and answer on that site.
Briefly, each XAF application consists of Modules. There can be standard (system) and extra (user-defined) modules. Each Module can contain business objects, so-called Application Model customizations, Editors, Controllers, and Actions to provide additional business logic, customize UI and provide interaction between framework parts. You can model and customize your application on each level listed above, including but not limited by the underlying framework's metadata and data store ones. You can find more information about the framework's architecture here:
http://documentation.devexpress.com/#Xaf/CustomDocument2559
I should emphasize that it is possible to override behavior of almost every part of the framework. For instance, create your own editors for detail and list forms, override certain standard controllers, etc.
If you experience any further difficulties with our framework, feel free to contact us through our Support Center. We will be always glad to not only answer you questions, but advice a certain technical or design solution, provide some example code, etc.
I'm still learning all of the powers of OO design and have much more experience in database (in particular, E-R) designs. Each time I approach a problem and attempt to come up with a design following OO strategies, my diagrams(UML classes, for example) come out looking like an ERD. I've read/heard it's then smart to map a class to each table and work from there... But this never really seems to get me anywhere and my designs have very high (bad)coupling which, as I understand, is a big "no-no" in OO.
A few google searches returned a few hits on moving from E-R to OO, but nothing that really drilled it home for me. Does anyone have any materials on this topic, or have perhaps struggled with this similar problem?
To expand just a bit, my attempted OO designs tend to move towards an implied persistent data storage element which doesn't necessarily exist in an OO design.
Thanks for any guidance!
Database Systems: A Practical Approach to... is the textbook(chapter 3~4) which I would recommend.
I think the fundamental differences in data(relational data model) and program are the main gap between E-R and OO design. You may draw database schema design in UML, but it doesn't
mean that realational data model would become any sensible meaning of OO paradigm.
The programs, from another side, focus on processing correctly with reusability discipline. The data, however, focus on persisting correctly with performance discipline.
Although there are some techniques to ease the gap(lik O-R Mapping), but the basic purposes on data/program are not totally the same.
So I think the OO is just a technique to abstract the design, not the goal of the design.
I'd suspect from what you write that you need more experience with / knowledge about some core OO design principles, in particular inheritance and polymorphism. A good understanding of these concepts can help you better understand the relationships between your objects, and the ways in which they should be coupled.
Given your comments about your OO designs moving towards an implied persistent data storage element, you might also want to look into such concepts as Aspect Oriented Programming (Spring is a great tool for this). Also, look into what an ORM such as Hibernate can do, and how it does it (this may be a bit advanced, though).
There's really only one way to learn object-oriented software design: learn it from scratch. You won't find any shortcuts for converting your knowledge of another software design method into an understanding of object-oriented design. You need to start with the basics, just like everyone else: encapsulation, abstraction, is-a and has-a relationships, etc.
E/R concept model can help you whenever you need to design relationships between an entity. You shouldn’t care how they are going to be implemented at design time : the can be converted into Class,DataTable,XML,....
what you are asking it's a bit different. In a small system or when the business logic is not too complex it is possible to have a domain model object that looks like the Data Table.In this case you can have an object per table. This pattern is called "Table Module Pattern"
http://martinfowler.com/eaaCatalog/tableModule.html
Use Nhibernate or EF or any other ORM in a system like the one mentionated earlier it's a waste of resource and time because you are adding a layer that you don't really need
can you please describe what an n-tier architecture is. what is a data access layer? what type of code would typically go into this data access layer class? i have basically the same question for the business access layer. what type of code typically goes there? finally, can you also explain, in high level, how these layers interact with each other? thanks.
http://en.wikipedia.org/wiki/N-tier
Microsoft Patterns & Practices site is a good resource for this type of stuff. They've published a book ($$$ for print, free-as-in-beer ebook), the Microsoft Application Architecture Guide v2, which has a solid overview and walkthrough of N-Tier:
Application Architecture Guide: Design Fundamentals
Google is your friend, as is wikipedia as STW pointed out. You might wanna check out this though - http://weblogs.asp.net/scottgu/archive/2009/03/10/free-asp-net-mvc-ebook-tutorial.aspx as it gives a practical example.
I've been mulling this around in my head for a few years, so I'll just throw it out and see what happens:
N-tier is crap.
When developers first learn about it, they twist their code into all sorts of hideous contortions to make it fit "n-tier". Then (if they are not incompetent) they grow up and just sort of give up on that approach. Then (if they are reasonably competent) they realize that all the other real sorts of architecture, which you have to learn over time and which can't be distilled into this ridiculous one-size-fits-all 3-bucket magic, do frequently (sort of) map to the 3 tiers. But they aren't built on the 3 tiers - you don't start with 3 magic buckets and everything falls neatly into them. 3 tiers simply tend to emerge from a proper design. Starting with 3 tiers is backwards.
So my advice - which may be wrong, I'm just testing this idea out - is don't try to understand 3-tier until you understand all the other, more basic patterns and practices, and you've built some solid software using them. Feedback welcome.
If you're like me, you learn by playing with code rather than reading articles. Here's a little example tutorial.
Oh, and also read up on the difference between a Tier and a Layer. It's a pet hate for some StackOverflowers :)
I would like to know the best practice for a designing a simple CRUD application with some screens updating various tables (like admin pages to maintain static data for an application). the simplest way would be to drag a data grid/gridview, bind it to a dataset and use a data adapter for CRUD operations. but if this application needs to be scalable, lets say to add any extra UI/business logic in future, then is there any design pattern that can help with this? should I be using an object data source control and bind it to business objects instead? or are there any better ways of doing it? should I build a complete layered application or will that be overengineering for this requirement? any examples for UI design would also be helpful. thanks.
If you are looking for a really quick and easy approach, you can look at using Dynamic Data
http://www.asp.net/dynamicdata
on top of a Linq2SQL or EF4 backend - hardly any code needed at all.
+1 Oded. No offence RKP but you might be confusing "simple" with with "effective" or "value-for-money". I also think you might want to be more clear about exactly what it is you're after: example UI designs is quite a different issue from the logical architecture. Anyway - good on you for asking.
If this is a "tactical" solution: not expected to have a long life-span, or is a quick-and-dirty dev tool then how you build it might not be such a big issue. (also beware that short-term tactical apps can end-ed being long-term strategic ones - were working on an app now that the business see as a "temporrary" tool: they see it only being used for the next 5-10 years (!)).
If it's a tool the "business users" will use, then it's quite likely they'll expect changes overtime: depending on what the app is for a simple pass-through CRUD app might only cut the mustard for a short while.
So I guess this is where your admirable desire to look at best practice comes in.
Are you familiar with OO design? A lot of the principles behind good OO design also apply at the architectural level (SOLID, Common Reuse, Common Closure, Loose Coupling, Stable Dependancies and Stable Abstraction Principles).
lets say to add any extra UI/business
logic in future
So - this is where you need to consider up-front how you will seperate concerns and allow for growth: architecture doesn't mean you have to do a big upfront design, it just means you need to have an idea of how you'll grow the application as requirements grow..
To finish:
Have a good look at the different system quality attributes and work out which ones are particularly relevant to the system. prioritise them.
I get a lot of mileage out of Dependency Inversion (The D in SOLID) - abstract out things like data access early on.
For me the other really key "best practice" is to pay attention to SRP (the S in SOLID),
http://www.asp.net/mvc is my bet. It's easy to start with and get going... You won't be dissapointed. :) StackOverflow itself is built on top of it.
I've been looking for open source examples of SOA applications, but most of the times I find simple tutorial hello world style examples that introduce the tricks of the respective middleware.
Do you have any suggestion about any middle to big size example with multiple layers and/or governance ? Isn't it some kind of common example (a la Lena in image processing) for SOA ?
Any suggestions ?
Thanks
What you may want to do is look at OpenESB:
http://wiki.open-esb.java.net/Wiki.jsp?page=OpenESBIntroductionTutorial
Once you have a working example then you can look at extending it yourself, as you will have the tools to do that, and see how you can get applications to work together.
Are you trying to learn how to use SOA or do you want to look at an architectural diagram where it has been used in a complex system?
The introduction above is for learning to use it, via OpenESB, I don't know where you may find a diagram of a large example of SOA.
It may help if you could narrow your question down to what precisely are you looking for.
I do not know of a detailed example you seek. If you are taking an approach of learning how to use SOA by checking examples, it may be a bad approach. You need to first know what and how you are going to do your SOA and then see what features are are enough for your needs.