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.
Related
I recently worked at HP doing several ASP.NET MVC3 projects as I came from a software background I was relatively new to the inner workings of MVC3 as well as the best practices.
During this time I somewhat adapted the coding style of fellow co-workers and ways of designing my pages that I still stick with to this day. With all of this in mind my main question is what would anyone recommend for learning material; books/videos/tutorials. I can learn from any of those resources and I would love to know that I am coding properly.
I have several projects under my belt and many large scale business solutions that I have coded using Razor and ASP.NET but there are times where I feel that what I am doing is either very hacky or just an inefficient way of coding things. The larger the project is the more difficult it becomes to add new features because of this.
I think this is my lack of experience in coding but at the same time I would like to overcome this and I feel that with the mass experience I do have with MVC3 I could adapt to a easier style or design pattern that would help me not only optimize my code but become a much better web developer. If anyone has any suggestions on books or training sites or anything please let me know as I would love to get better.
Thanks in advance to anyone that has been in my shoes and is willing or capable of recommending anything!
I was dealing with the same issue and found it useful to make a mind map. While it's impossible to give you a full understanding, I can try point you in the right direction with some basic ideas.
download/view (http://www.xmind.net/share/highroad/mvc3-design-pattern/)
Are you familiar with design patterns? Well they exists with MVC applications too :)
If you want to talk the talk and understand what people including myself are talking about, you would need to know the typical design patterns that come with building what they call enterprise level applications. These design patterns are the only real way to begin to understand the concepts.
These patterns structure complex business logic in ways that have become the tried and tested solutions (design patterns) to the design challenges the developer's face.
In the diagram notice there are 3 main layers:
Presentation Layer
Business Logic Layer
Data Access Layer
Some of the highly used design patterns when dealing with Model View Controller in ASP.NET include:
Business Logic Layer Design Patterns:
Active Record. Models relate exactly to the database like in lightweight frameworks e.g. Ruby on Rails). When creating new MVC3 application with ASP.NET and scaffolding views and controllers, this is how it sets it up. Is perfect for less complex applications. So why not just use Ruby on Rails? I would
Domain Logic Layer. Uses MVC with the controller containing very little code and create lots of extra models that can do complex logic, the MVC is only for presentation. Often with this style of layer, a lightweight layer called a Service Layer can be used to call all the functions in the Domain Layer from the controllers i.e. the controller calls the method in the Service Layer class which calls the domain layer. This design pattern seems to be very popular with people who enjoy object oriented programming. See link below to my (quite basic) project designed using Domain layer.
Transaction Script - Use the controller to do a lot of the logic work per action, the problem is a lot of actions need to do the same things so there will be code repetition
For the Data Access Layer:
Something like entity framework models combined with a repository which can perform any SQL queries you need.
Not going into all the patterns for this layer but they include: Data Mapper
With simple apps, there is no real data access layer, it only becomes necessary if you use the Domain Layer in the business layer (which usually is the case)
Depending on what structure your application takes, your Models will mean very different things. In general they will not be models linked to the database (the default when creating a new app makes them like this). Instead they will be ViewModels which are only responsible for holding data that each of the views will need.
I have created a ssample app which you can see here.
https://github.com/testbrian/enterpriseframeworksB
I don't know if this is an example of an enterprise solution, but I have learned a lot from the techniques found in RaccoonBlog. I like how the Layout.cshtml and other razor files use RenderAction to modularize the views.
The project is an example of MVC3 using RavenDb, but it's also one of the best real world applications I've seen since it's actually used in production.
Hope this helps.
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'm in the middle of creating a fairly large flex application, and over time, it's started to edge toward unmaintainability.
I'm using 3 external library projects which are still small enough to remain maintainable and reusable, but the main project seems to be impossible to keep organized.
Part of the problem seems to be that I have about 30 objects inheriting from a single abstract superclass type object. All of child objects have both a logic component and a ui component which are tightly integrated to each other. The superclass object has about 60 shared methods and properties, most of which can be overridden in any of the child classes, a few of which should be overridden in all child classes.
To add to the complexity, these have to communicate between themselves, and this is usually via the container object they reside in. Additionally, the main project has to create value objects out of these so they can be sent to a FlourineFX backend for storage, and additional authentication/authorization logic.
I've created much larger projects in languages from old MS BASIC (pre VB), Ada, VB (3 to .Net 1), C++, and C# without this problem. (well, old VB tended toward this problem because of the same tight integration between UI and logic) So, is there any thing I'm missing, or is there any best practices that I can implement? (even if that means rewriting entire swaths of code)
And yes, this may be an extension to this conversation.
Do you use any framework implementations in this project? A framework would help modularise a lot of this complexity and hopefully remove a lot of the dependencies you seem to have between the application logic and views.
I'm a massive advocate of the RobotLegs framework which implements the mvcs pattern and offers dependency injection for use throughout your project. There are others out there such as pureMvc, Cairngorm, Mate. Have a look around and see which best suits your project.
It sounds to me like you really need to do a big refactor which is a risky process in such a large project. It could be well worth it if you're struggling to maintain it. If you are going to refactor definitely refactor into a framework. It's probably the area that will give you most bang for your buck (pound for the brits ;) )
James Hay's conversation starter is a good one, but for HUGE applications I would take time to test and consider memory management for some of the suggestions in that answer/conversation. RobotLegs is great and all, but I would worry about 'over-singletonization' and potential memory management issues that it would create (though I have to admit that I've never used and avoided robotLegs because of it's use of singletons).
If you were thinking IoC and dependency injection (like that which robotLegs provides), I'd suggest a look at swiz -- I really like the new 'instance-direction' swiz has taken. My only issue with it (in the current beta) is they have some cleanup issues, though these issues are easy enough to remedy (look through their source and any time you completely remove a component from the stage you'll have to play the profiling game and make sure everything is getting cleaned up --- we had to create temp functions to remove the changewatchers and destroy 'display list bean instances' until they get that stuff fixed).
The project I lead had many of the potential issues you must be worried about. Our ERP app has thousands of modules and the thing is running on client machines for hours/days at a time, constantly loading and unloading modules. Garbage collection and memory management were and is THE issues.
As for using mate, the annoying carhorn, or pureMVC, we created our own framework two years ago. It borrowed ideas from cairngorm, but overall my suggestion is to use whatever you can quickly learn, understand and teach while thinking about garbage collection. Our internal Model and View classes now use swiz (for newly developed modules) and this has made maintainability and code readability super smooth.
I hope my blabbing has helped at least a bit.
Best of luck.
It seems like you just need a clean separation of UI and domain components. Look into the component guidelines and the Presentation Patterns discussed by Martin Fowler, especially the Presentation Model.
To bring these pieces together, you might want to use an IoC container like Spring ActionScript. This is a non-intrusive framework that allows you to keep layers separated.
Don't let a framework get in your way. I've seen massive misuse of frameworks like PureMVC and Cairngorm mainly because apply them in an all-or-nothing fashion.
We are currently designing a business application that has two primary requirements for it's UI:
1) run on the Desktop (WPF) for enterprise users to provide a rich user interface, interoperate with other applications, access the filesystem, work offline, work with special local hardware, etc.
2) run on ASP.NET/Ajax to provide several components of this application to customers (internet). Unfortunately Silverlight is not (yet) an option.
Even though we don't have to make the full application available on the web, some of these components are fairly complex and we would like to share as much UI code as possible with the WPF implementation.
What options do we have to reach this goal? Is there a pattern that works well with both technologies?
Update:
Thanks for the answers even though they don't include the one I was looking for! :)
I don't think UI generators are a good option. Like Eduardo pointed out you will probably end up with problems in both worlds. I will check out Sculpture though.
I've been thinking along these lines for a while now, and I've yet to come up with a great answer. That being said, here are some of my thoughts:
If you used some variation of the various MVP/MVC/MVVM UI methodologies and you were very disciplined in this approach (i.e. not mixing presentation stuff with behavior stuff), you'd probably be farther down the road.
You might consider investigating the various DSL toolkits that have cropped up, the idea being to create a simple "language" to describe your UI at a high level and generate a representation of that UI in WPF/ASPX.
Also, I ran across this recently. I have no idea how good it is. I'm planning to take a closer look when I get the chance.
Good luck!
The unfortunate truth is that Asp.net/ajax (the web in general for that matter) and WPF (and heck, let's throw WinForms in there for good measure) have very different User Interface models and what works well for one is not necessarily going to work well for another. That's not to say that you can't share logic between applications written for either technology, but, I'll make a stretch here, your UI logic is not going to be in that category.
I've been using a variation of MVVM for WPF and ASP.Net MVC most recently and I'd say they are very good fits for the technology at hand. However, while they are very similar, they have their differences and I'm not sure you could write an abstraction layer (in any decent amount of time) that could take advantage of the great features in both technologies.
Ultimately, I'd say that your best bet is to follow some SOA patterns and extract as much of your business and data access logic into common libraries as possible. Then, write separate user interfaces in WPF and Asp.net to take advantage of those common libraries. This is the approach that my company is taking at the moment, and it's working like a charm.
It may seem daunting to write your UI logic twice (once for asp.net and once for wpf), but I think it's worth it so that your code can fit the patterns and practices that best fit those technologies.
As an aside, even though Silverlight is not an option, have you considered XBAP?
If a former job we did something similar. As Daniel Pratt says, we describe our interfaces in XML and then a render will create the form, report or whatever we decided to create.
We have to provide a Javascript function to do some UI validations in the HTML render, and a call to a java function in the Swing render.
Beware that you may end with imperfect apps in both worlds.
I am just starting a new ASP.NET project and using the MVP pattern. I did consider the MS MVC but it is not released yet and would be a big learning curve for some people on the team, so I opted for MVP now and possibly future projects MVC.
Anyway, it seems I will have a single Controller/Presenter class for every webform I have it the project. This is a lot of extra classes, essentially doubling the number of files in the web project. Is this how other people structure MVP or what are the alternatives?
This seems to be a common misconception -> "More files/classes == more complex"
The reason we chose to follow a UI separation pattern is to help separate concerns, make code easier and cheaper to change and maintain and (big, important and) we can unit test the complex parts and still keep the UI layer slim.
I'm going with the beta ASP MVC. The reason being, that while it is still only a beta (PDC very soon, that may have an impact on release and we've had 5 preview releases) it has a better framework to support this style than I could write in a reasonable time frame.
You could of course go with another framework, like castle monorail.
I think a lot of it depends but in most cases that is really the way it ends up going.
I personally use a n-tier architecture with data, business, presentation code. (Who knows what actual format I follow). I do get a lot more files than if I did everything in the aspx, but the code is much easier to manage.
To your question - I have seen many different takes on MVP and seen nothing that reduces the number of files, and I can't think of a way to reduce the number of files.
In my experience, I have reused view interfaces and even code behinds where the view structure is identical, but presenting different data. And you could also think of reusing the controllers where applicable.
I think it is worthwhile to note that having more files will be a natural consequence of moving to a more agile and test-drive development and developers will find it more and more natural as they go. (Just like some of us find it very natural having lots of methods inside a single file...)