The service layer could and usually adds other functions required in many applications. Typically i add auditing and security in the service layer. I think it's a natural place to check if the user is allowed to perform the action and then add a log entry of
who has done what do an audit trail. Especially if you're using 3 rd party brokers and youre not in control over what you can extend and when in the lifecycle of the entitys. Thoughts anyone? Regards /M
that's a fair point, however if you have business logic, imho it should be in the business entities. adding a non-oo service layer wont give you anything else here. i dont know of any broker that doesnt allow some type of callback to the object both pre-processing
(BeforeUpdate for instance) and post-processing (e.g. AfterUpdate)
It's separation also a separation of concerns and allows me to use different security models for different services, and also in some cases transform the information returned based on the current security level. Having all this logic together with the entity
will make it a quite large and it will have multiple responsibilities which might make extensibility and maintenance suffer. For simple needs I guess it would be ok to go to the broker directly, but then again for even simpler needs you could go dataoriented
straight through as well ;). I thing auditing and security belongs in the service layer and not in the business entity layer, but that of cause can be argued ;) /Michel
I all, I was hoping that the persons asking the question could have an holistic view of software development. In any case here is my humble opinion. What I'll say next is not a silver bullet much as O/R Mappers are not. O/R Mappers exist to solve the problem
of persisting objects to relational database as they are defined in classes and as transparently as they can. That is it, nothing else, nothing more. Cklein wrote: “I just don't get the benefit of: //I guess NUNO is talking about having UserInfo and User class?
//UserInfo is a struct, while User wrap all the UserInfo and some logic in it? //Thus we have 2 classes for every entity, I don't get it. :-) Model.UserInfo user = UserManagementService.Instance.GetUser(userid); txtUser.Text = user.Name; or IDataReader ur
= UserManagementService.Instance.GetUser(userid); txtUser.Text = ur["Name"];” I have not provided that comparison have I? So I can’t see the benefit in that scope and naturally neither can you Cklein as we think alike ? M7 wrote: “pretty much all you succeed
in doing with UserManagementService is make it more work should you ever need to get a user by criteria that you dont already have in UserManagementService.” Where you would code those criterias M7? Anyway here goes a further explanation of my point of view
for all it is worth. IMHO, the main concept sustaining a n-tier is separation of responsibilities and un-couplement. That is, we have realized that it is good practice to uncouple the most we can the UI Layer, Business Layer, Persistence Layer and System Integration
Layer. What people don’t often realize is that we always have had a Business Layer (At least I had), either coded in modules, dll’s, stores procedures, etc. Also we had a very basic Persistence Layer ADO and now ADO.NET. If we take uncouplement one can argue
the concept of an n-tier system is basically one of packaging, but if we don’t then it not just that, is it? Having this in mind consider what people that work with Objects with the help of an O/R Mapper are advocating. Basically the reason why people group
functionality in modules, service or components is basically due to the fact that they don’t use an O/R Mapper. With an O/R Mapper such things are not needed anymore, because the O/R allows the UI Layer to work with strongly typed objects that have encoded
the business rules. Within this respect the business rules are abstracted already so are the dynamics of the problem domain (The Business Layer only have objects concerning the problem domain, Problem Domain Model). So why a Services/Components? So why it
may the case that having the UI Layer work with business entities directly may not be at all that good? Remember that IMHO uncouplement is deep into the concept of an n-tier system? Well, the answer lies in there. If you allow the UI Layer to work directly
with business entities (that is not using a business facade/service/component) means that the UI Layer will be entirely dependent on the structure of the Problem Domain Model. Not only that but will require that the Business Layer is embedded within the application
itself otherwise performance issues will rise (I’ve some people packaging Order and Order Lines as unique COM objects, what a mess). If your Business Layer is embedded in the application and you don’t care for anything else then read no further ? What I am
saying (and this is hugely important) is that in enterprises of any size and complexity the Business Layer is too hard a problem to solve in one bite. The notion that any application can wholly contain all the relevant parts of the Business Layer is just not
feasible except by implementing stove-pipe systems with all their attendant problems. Embedding the Business Layer in the application is the cause of the customer in every application problem that banks continue to spend enormous amount of money to solve.
So I am specifically referring to Business Layer services as the way to break down and distribute the Problem Domain. This is what operational customer repositories do. They implement a piece of the Business Layers independently of the applications that use
it, and each application invokes it as a service. Note that this thinking leads inevitably to assuming that a separation of Business Layer from the application (UI Layer) is at least desirable. Another way of describing this is that I was reversing the conventional
way of thinking about applications as the centre of things linked together by more-or-less ad hoc interfaces. And saying we can think of applications as assemblers of Business Layer services. The Services and most part of the Business Layer is what is stable
and applications (the UI Layer) are in comparison transient and disposable. So to achieve the uncouplement between the UI Layer and the Business Layer we need to develop facades around the Business Layer (The so called Services) that basically only serve data
and perform operations on that Data from the point of view of the user (the UI Layer). Inside they work with Business Entities and use an O/R Mapper to persist these objects. What do you think about all this? Nuno
> Where you would code those criterias M7? in the front-end, where else? that's what wants the objects after all. the user interface wants a list of all users who live in england... so it asks the object broker for the list. simple, and makes the app easy to
maintain and extend. yes, you lose the decouplement between the ui and the business entities, but i personally WANT them coupled. that's why i wrote the business entities in the first place :)
m7, full agreement. THis is how we do it, too. We ask for the objectsi nthe frontend, we bind them in the frontend. And it just works and saves tons of time.
"yes, you lose the decouplement between the ui and the business entities, but i personally WANT them coupled. that's why i wrote the business entities in the first place :)" ?????? Nuno
::This is the same as having SELECT statements spread all over the UI Layer :) Nope, it is not. And yes, it is. But the point is: the UI HAS TO KNOW the layout of the object and the names of the properties anyway. And funnily this is the level you ask for things.
AND you have way less "SELECT statements" in there than you have select statements without an O/R mapper.
@Thona "And it just works and saves tons of time. " It works in what scenario. Becouse I agree it works and I have scoped the scenario -Business Layer embedded in the application! When you want to decouple be prepared to rewrite all your UI Layer, but if that
is not a concern by all means use Business Entities in the UI Layer. Nuno
michel_andre
Member
410 Points
82 Posts
Re: Auto-creation of Business Entities in .NET?
Nov 16, 2003 10:30 AM|LINK
m7
Contributor
4225 Points
843 Posts
Re: Auto-creation of Business Entities in .NET?
Nov 16, 2003 10:33 AM|LINK
michel_andre
Member
410 Points
82 Posts
Re: Auto-creation of Business Entities in .NET?
Nov 16, 2003 10:40 AM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: Auto-creation of Business Entities in .NET?
Nov 17, 2003 09:03 AM|LINK
m7
Contributor
4225 Points
843 Posts
Re: Auto-creation of Business Entities in .NET?
Nov 17, 2003 09:39 AM|LINK
thona
Member
20 Points
2923 Posts
Re: Auto-creation of Business Entities in .NET?
Nov 17, 2003 09:43 AM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: Auto-creation of Business Entities in .NET?
Nov 17, 2003 11:32 AM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: Auto-creation of Business Entities in .NET?
Nov 17, 2003 11:43 AM|LINK
thona
Member
20 Points
2923 Posts
Re: Auto-creation of Business Entities in .NET?
Nov 17, 2003 11:47 AM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: Auto-creation of Business Entities in .NET?
Nov 17, 2003 12:01 PM|LINK