Архитектура приложений на основе данных .NET, мнения, передовые практики

Question

Я хотел бы задать вопрос о создании приложений в .NET, которые используют данные из базы данных. Есть много технологий и шаблонов, и я пытаюсь соединить все это.

Я создаю настольное приложение с локальной базой данных, поэтому я выбираю SQLServer CE + WinForms, но я бы хотел сделать это как можно более общим. Я не разбираюсь в других технологиях (Java и т. Д.), Но если там есть какие-то хорошие решения, тогда вы можете написать о них.

Я хотел бы спросить ваши предложения, мнения и передовые методы, которые вы используете для создания приложений. Вы бы добавили или удалили какой-либо из перечисленных слоев? Какие технологии вы предпочитаете?

Итак, вот основные слои приложения:

1) SQLServer CE/SQLServer/Oracle/IBM DB2
--------------------------------------------------
2) LINQ to SQL/Entity Framework/NHibernate/ADO.NET
--------------------------------------------------
3) Data Transfer Objects
--------------------------------------------------
4) DTO-to-BM/Data Access Objects
--------------------------------------------------
5) Business Model
--------------------------------------------------
6) MVP/MVC/MVVM/PM
--------------------------------------------------
7) WinForms/WPF/ASP.NET

1) Это классическая реляционная база данных. Итак, первый вопрос - использовать хранимые процедуры и триггеры или нет? Я буду использовать SQLServer CE, так что никаких SP для меня, но мне было интересно, являются ли люди за или против. Мне кажется легче (более проверяемым, более проверяемым) НЕ помещать логику в БД. Бизнес-правила будут помещены в бизнес-уровень - возможно, в какую-то «структуру».

2) Это уровень доступа к БД.

3) DTO - простые POCO. Они нужны?

4) Отображение между DTO и BM. Ручной код, AutoMapper или, возможно, наследство? Или, может быть, DAO - абстрактные объекты для доступа к базе данных, которые возвращают объекты из BM?

5) Бизнес-объекты, которые строят бизнес-модель. Я бы положил здесь все бизнес-правила и проверки. Но нужен ли этот слой? Или вы бы поместили все деловые вещи в слой 3?

6) и 7) Создание пользовательского интерфейса с использованием BM.

Answer 1

Я хотел бы попросить ваши предложения, мнения и передовые методы, которые вы используете для создания приложений.

Всегда абстрагируйте реализацию доступа к данным от бизнес-уровня. Укажите договор, используя старый добрый C # интерфейс ; тогда вы можете иметь несколько реализаций - любые неудачные технологические решения сводятся к минимуму, поскольку вы можете реализовать их с помощью чего-то другого. Другие могут также разработать свою собственную реализацию, если они действительно этого хотят (решение является более расширяемым), и его проще тестировать.

Мне нравятся те слои, которые у вас есть - как указывает Зихотки, вы можете потерять пару; до тех пор, пока у вас есть отдельные уровни бизнес-логики пользовательского интерфейса и доступ к абстрактным данным, я был бы счастлив.

Вы бы добавили или удалили какой-либо из перечисленных слоев? Какие технологии вы предпочитаете?

Я не могу говорить о специфике, но это зависит от того, что вы хотите сделать, и кто будет работать над системой, например: это будет с открытым исходным кодом? Если ваша клиентская база включает разработчиков, вам нужно оценить, чего они могут хотеть, и сбалансировать это с вашими другими потребностями. Я думаю, что ваш список в порядке. Я бы не стал использовать NHibernate, поскольку у меня не было никакого опыта работы с ним, но это больше основано на личной истории, чем на доказательствах.

Если вы рассматриваете инструменты ORM (например, NHibernate), я советую вам рассмотреть LightSpeed ​​, мои друзья (которых я уважаю) ОЧЕНЬ высоко ценят это.

Итак, первый вопрос - использовать хранимые процедуры и триггеры или нет?

Я бы настоятельно рекомендовал использовать SP, особенно в веб-средах, поскольку (все сделано правильно) они предлагают более высокий уровень защиты от атак SQL-инъекций.

Кроме того, то, что вы используете SP, не означает, что в них есть бизнес-логика.

Триггеры - что они делают? Надеюсь, ничего «бизнес-логика» не связано:)

Бизнес-объекты, которые строят бизнес-модель. Я бы положил здесь все бизнес-правила и проверки. Но нужен ли этот слой? Или вы бы поместили все деловые вещи в слой 3?

Как вы, наверное, уже разобрались, я твердо верю, что вся бизнес-логика должна быть на бизнес-уровне, она будет более пригодна для повторного использования, и преимущества согласованности должны быть очевидны:)

Answer 2

Если вы хотите использовать некоторую встроенную базу данных sql, вам следует взглянуть на SQLite . Он обладает гораздо более полезными функциями, чем SQL CE, и работает быстрее и без проблем. Или даже больше, я рекомендую вам использовать некоторую базу данных документов или объектов (например, db4o ). ИМО, это упростит ваши DAO и много кодирует.

1, я предпочитаю использовать ORM, и я использую хранимые процедуры и триггеры очень редко и только в устаревших приложениях. Гораздо проще иметь дело с кодом на C # и иметь все в одном месте. И вы правы с логикой и бизнес-правилами.

2, я предпочитаю использовать NHibernate как наиболее зрелую, мощную и настраиваемую среду. И я также рекомендую вам взглянуть на NhProf (словом, одни и те же профилировщики существуют для L2S и EF).

3 & 4, просто удалите его, ненужный шум и обезьянья работа.

2 & 5, используйте вашу модель базы данных как BusinessModel (это очень легко с NHibernate). Проверьте это и это статьи.

6 & 7, для веб я выбираю MVC с asp.net mvc, для WPF - MVVM. Исходя из моего опыта, не используйте WinForms и Asp.Net, если у вас нет ограничений, таких как устаревший код. Гораздо проще и веселее разрабатывать, используя Asp.Net Mvc и WPF. И для них есть множество интересных и экономящих время фреймворков - MvcTurbine , MVC Contrib , SharpArchitecture для asp.net mvc и Caliburn , WPF Toolkit , Cinch , MVVM Light toolkit и многие другие.

Также я рекомендую вам ознакомиться со следующими статьями и примерами, которые могут помочь вам улучшить дизайн вашего приложения:
http://nhforge.org/blogs/nhibernate/archive/2009/08/27/nhibernate-and-wpf-validations.aspx
http://nhforge.org/blogs/nhibernate/archive/2009/11/07/nhibernate-and-wpf-the-guywire.aspx
http://msdn.microsoft.com/en-us/magazine/ee819139.aspx
http://code.google.com/p/unhaddins/source/browse/#svn/trunk/Examples/uNHAddIns.Examples.WPF

Answer 3

Лично я склонен иметь настройку, которая выглядит примерно так, для всех моих приложений (независимо от ASP.NET/PHP/etc):

[database (mssql, mysql, etc)]
[dal/orm (nhibernate, subsonic, phpactiverecord, etc)]
[controllers (business logic goes here)]
[models (often direct mirrors of the DAL, but not always, depending on controller logic; if you have a simple enough data structure, you can possibly eliminate this)]
[rest (simple web interface to the controller methods)]
[user interface (extjs/jquery/etc)]

В этой настройке уровень DAL отвечает просто за упрощение запроса к базе данных, контроллеры отвечают за загрузку моделей в соответствии с тем, как конечные пользователи используют данные, и Пользовательский интерфейс полностью AJAX.

Причина, по которой у меня есть модели данных и , заключается в том, что они не всегда отображаются один на один. Они, как правило, очень близки, но я могу выбрать хранить что-то в базе данных одним способом, но представлять это пользователю другим способом. Таким образом, вы также можете переделать слой данных, не взорвав при этом ваш пользовательский интерфейс:).